IRC logs for #farmOS, 2025-05-02 (GMT)

2025-05-01
2025-05-03
TimeNickMessage
[10:37:16]* farmBOT has joined #farmos
[11:19:33]<mstenta[m]>paul121 symbioquine What do you think about requiring farmOS users to upgrade to the latest 3.x before they upgrade to 4.x?
[11:20:23]<mstenta[m]>If we're OK with requiring that, then it means we could remove all the existing update hooks in our modules, and implement [hook_removed_post_updates](https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Extension...)
[11:21:09]<mstenta[m]>The way that works is: you delete your update hooks, and implement hook_removed_post_updates() to return a list of all the ones you removed. Then, if someone tries to run drush updb and they haven't run all of the update hooks that are declared, it shows an error.
[11:21:16]<mstenta[m]>I tested it out, and this is what it shows:
[11:21:16]<mstenta[m]>```
[11:21:41]<mstenta[m]>* $ ./drush updb... (full message at <https://matrix.org/oftc/media/v1/media/download/AWlmzAbq92wAgqMgiyDG2nlU...)
[11:22:04]<mstenta[m]>* ```bash... (full message at <https://matrix.org/oftc/media/v1/media/download/AZBN6hXr1zm1AmJMKFwAoawn...)
[11:22:21]<mstenta[m]>It would be nice to remove all the old update hooks as a 4.x cleanup.
[11:22:43]<mstenta[m]>But it puts the burden on users to make sure they are completely up to date first.
[11:23:06]<mstenta[m]>But maybe that's a good thing too? In theory, if you're updating from a VERY old version, these update hooks might not run in the order we originally expected them to.
[11:23:28]<mstenta[m]>So over time (and multiple major version upgrades), that might lead to issues.
[11:23:49]<mstenta[m]>(If we were using hook_update_N() then it wouldn't be an issue, but we use hook_post_update_NAME() for most updates)
[11:24:55]<paul121[m]>Ah that's interesting. I would be supportive of that
[11:25:23]<mstenta[m]>Cool - I can put together a PR for it. Wanted to sanity check before I did...
[11:25:57]<mstenta[m]>I was going to start working on removing jsonapi_extras and realized we'll probably need an update hook for that... which would be the first one in 4.x. So it probably makes sense to get rid of all the 2.x and 3.x hooks first.
[12:23:10]<symbioquine[m]>I agree that it is pretty reasonable to require that one step through each major version for an upgrade.
[12:23:47]<symbioquine[m]>The verbiage "a version prior to 4.x" could be clearer however...
[12:25:03]<symbioquine[m]>It would be slightly clearer (IMHO) if it said something like: "Update to the latest farmOS 3.x release before attempting to update to farmOS 4.x"
[13:34:51]<mstenta[m]>Yea agreed that drush updb language isn't great
[13:34:51]<mstenta[m]>Not sure how much control we have over that
[13:34:52]<mstenta[m]>But at the very least we can make it very clear in our release notes
[13:34:52]<mstenta[m]>I'll include that in my PR
[15:46:17]<mstenta[m]>https://github.com/farmOS/farmOS/pull/962
[16:26:46]<mstenta[m]>paul121 symbioquine: Starting to work on removing `jsonapi_extras`, but just realized: I think we'll need to deprecate and uninstall it in 3.x first, and then remove it in 4.x, like we did with `exif_orientation`.
[16:27:09]<mstenta[m]>So we'll need another 3.x release.
[16:27:41]<mstenta[m]>I'll work on a PR against 3.x, and another followup for removal in 4.x