| hestenet (he/him) | Tim from the DA, in Portland OR |
| mikelutz (he/him) | Hey all. :drupalparrot: |
| nicxvan | Hello everyone |
| quietone | HI, catching up |
| Björn Brala (bbrala) | Hi |
| Kristen Pol (she/her) | Kristen, California, catching up |
| VladimirAus | Vladimir [Brisbane, Australia] |
| catch | #3108658: Handling update path divergence between 11.x and 10.x#comment-15602211 we might have a solution for this but it involves adding some new stuff to the update system and probably needs to happen both before 11.0.0 and also before we commit any more updates. |
| nicxvan | I'm not sure if this is the right meeting for this, but I've been trying to push this forward and it feels appropriate: #3400254: [policy, no patch] Add a "developer tooling" topic to Drupal core |
| Gábor Hojtsy (he/him) | The alpha/beta releases deserved their own thread IMHO 🙂 https://drupal.slack.com/archives/C03L6441E1W/p1716228203210899 |
| Gábor Hojtsy (he/him) | The remainder of deprecated APIs have also been removed. #3447307: Remove remaining deprecated code from Drupal 11 🙂 |
| VladimirAus | Drupal 11 releases for the following modules:https://www.drupal.org/project/securitytxthttps://www.drupal.org/project... |
| Gábor Hojtsy (he/him) | See #3418267: Support PHPUnit 11 in Drupal 11 |
| Gábor Hojtsy (he/him) | @mondrake, @alexpott, @longwave, @catch have already been on this one 🙂 |
| mstrelan | Would be good to get this in #3445847: PHPUnit 10 behaves differently when invoked outside web root |
| Gábor Hojtsy (he/him) | I'll present my Drupal 11 session and several core committers will be there 🙂 https://ddd2024.drupalcamp.bg/ |
| Gábor Hojtsy (he/him) | @catch raised this[#3108658]#comment-15602211 we might have a solution for this but it involves adding some new stuff to the update system and probably needs to happen both before 11.0.0 and also before we commit any more updates. |
| mikelutz (he/him) | I’ve been braining on that a bit. I do think we need to come up with a better solution before drupal 12, maybe something with attributes that can tell us that update 12xxx is the same as 11xxx somehow so the system can be smart enough to skip certain updates. Of course there are still issues with ordering and I haven’t fully wrapped my brain around all the possibilities yet, but I’ll get there. |
| catch | What we came up with would be a stopgap on top of the current API but also I think it covers what we need for the immediate problem of 10.4/11.0/11.1 |
| mikelutz (he/him) | Yeah, was just reading it. I feel like there’s the solution we implement for 10/11 now which we are all going to need to be aware of and do a bit of extra work, but I’d love to find some system we could put into 11 to make it all easier for 11-12. |
| mikelutz (he/him) | Some way the function could go in once, be committed in the same place to both, with some attributes identifying the order, and the system could automagically know if it needs to be executed. |
| mikelutz (he/him) | #[UpdateInfo( updateNumber:10000, sequence10:401, sequence11:1, rerun:SKIP_IF_RUN(|RERUN.. etc )] |
| nicxvan | oh that's interesting |
| mikelutz (he/him) | Yeah, I don’t like it, I wouldn’t want to hard code the version numbers, and there are still backporting issues, particularly things being backport to the previous major but not the previous minor that are goigg to be an issue. but if we didn’t want to blow update hooks away in general in favor of something more complicated, it feels like we could decorate an update hook in some fashon such that the system could tell whether each one was ran or not, and whether it should run again. |
| mikelutz (he/him) | I need to think it through more. |
| nicxvan | yeah it's not trivial |
| mikelutz (he/him) | nope, not when the full list of updates has to differ between branches. a bugfix going into 10.4 and 11.1 but not 11.0 is blowing away my brain, lol. |
| nicxvan | well also, only the most recent schema is stored |
| nicxvan | you also can't even just flag the future update because there are situations where you might not know an update is going to be backported |
| mikelutz (he/him) | Yeah, but that could be changed by the time 12 rolls around if it made sense to. |
| nicxvan | well yeah |
| nicxvan | I think it's a combo |
| mikelutz (he/him) | Lets just store a master list of update hooks on a server somewhere and download them on demand instead of shipping them with the codebase. I see no issues with that whatsoever. :joy: |
| nicxvan | instead ofupdate_skip_future_update('system', 100101);you have some attribute or name of the future update |
| nicxvan | then the interstitial update numbers don't have to know the upstream change |
| nicxvan | but it's not a straight named update |
| nicxvan | I guess if you have multiple backports you can tag the same future update |
| mikelutz (he/him) | right, it would work, I was rather hoping to find someway to minimize or eliminate having to change the code when backporting, but it may not be possible |
| nicxvan | well, you have to change it anyway cause the id is going to change, that's the whole issue, but if you're changing just two things, it's easier |
| mikelutz (he/him) | Without a master list of updates that is the same and available to each branch |
| nicxvan | yeah |
| mikelutz (he/him) | Which isn’t going to happen.. |
| mikelutz (he/him) | My thought was we just start over at 100000, stop encoding the major version in the number, and keep the number the same across all backports. if one branch doesn’t get a particular hook, then that number is skipped in that branch, and the number you use is the next available in the master list. |
| mikelutz (he/him) | but there’s no way to make that simple to keep track of, at least not that I can think of right now. |
| nicxvan | oh that's interesting |
| nicxvan | still won't work though |
| nicxvan | for the same reason, different ports have a different number of updates (edited) |
| nicxvan | so yeah I don't think that actually works |
| mikelutz (he/him) | Wouldn’t matter, some would just skip some numbers. |
| nicxvan | it would matter for the same reason |
| nicxvan | update 1000001 happens on drupal 11 only since it's a new featureupdate 1000002 happens on drupal 11 and 10 since it's a security fixuser on 10 update gets 1000002 since they need that, update to 11.0, then update to the version that needs 1000001, you won't get it since 1000002 already ran (edited) |
| mikelutz (he/him) | Well, yeah, because we currently store the highest number function and that’s it. but 10000001 is tagged as sequence11:1 and sequence10:NULL, and 10000002 is tagged sequence11:2 and sequence10:1. When updating to 11, the system doesn’t care about the function number, it knows it’s run up to sequence10:1, knows it’s now on drupal 11, so it scans all the hooks for those with sequence11 values, and runs any that don’t have sequence10:1 or less tagged |
| nicxvan | AH, in combination |
| mikelutz (he/him) | We’d stop worrying about the hook number, and worry about the 10 ro 11 sequence numbers, and calculate which ones to run based on that. |
| mikelutz (he/him) | might need to store minor versions in there too for it to work, but I still think it’s making it too complicated to make an update hook. It’s one thing to look at an install file and see what the next number would be, it’s another to look through 3 branches to find out what the next number is in three separate sequences. |
| nicxvan | yeah |
| mikelutz (he/him) | maybe just tag it with the version numbers it should apply to, and calculate the sequence for each based on the hook number. |
| mikelutz (he/him) | So we’d store the last hook ran like : with version being probably . and when we detect that we are on a minor or major version higher than what we recorded as our last ran, we run through them all again, only running ones tagged with our version, but not also tagged with the last version we ran. |
| mikelutz (he/him) | unless it was tagged with “rerun” if we wanted to get that complicated. |
| mikelutz (he/him) | I feel like that’s closer, question is can I write it down so it makes sense… :shrug: |
| mikelutz (he/him) | Or more important, could I code it, make it work for contrib, be backwards compatible, and end up not having all the module maintainers hate me :joy: |
| nicxvan | if you take a pass at describing it on the ticket I'll take a look later |
| mikelutz (he/him) | I’m going to sleep on it, but I might try tomorrow. |
| nicxvan | ok, if you don't get to it first I'll make a pass when I'm back on |
| mstrelan | I agree we need to use attributes somehow to handle this. Magic function naming is a relic of the past. |
| mstrelan | Can probably do away with hook_update_dependencies then too |
| catch | The current idea in the issue should handle the case of an update being in 11.1 and 10.4 but not 11.0, this gave me a massive headache this morning but I think we've got something that will work:The 10.4 update will log that the update has run, including both the 11.x and 10.x update names in the logged information (in key/value).If someone tries to update to 11.0 from 10.4, we'll have the logged update from 10.4, and we'll be able to see that there's no equivalent 11.x update to run - at this point we can have an update requirements error that prevents going further and tells you to update to the next minor release of 11.x. |
| nicxvan | let me try to synthesize this onto the ticket |
| nicxvan | ok I tried to add a summary to the ticket |
| Gábor Hojtsy (he/him) | Raised by @nicxvan |
| Gábor Hojtsy (he/him) | See #3400254: [policy, no patch] Add a "developer tooling" topic to Drupal core |
| nicxvan | Yeah it would be great if anyone has advice on how to move this forward |
| Gábor Hojtsy (he/him) | @nicxvan I think Drupal core comitters have the authority to make this happen so they need to agree :) |
| Gábor Hojtsy (he/him) | If that does not work out Dries can make an executive decision. |
| nicxvan | did my comment in 13 address your question in 12? |
Participants:
catch, nicxvan, Gábor Hojtsy, VladimirAus, mstrelan, mikelutz
Comments
Comment #2
gábor hojtsyComment #3
mdmanouwer commentedHI would like to join
Comment #8
mikelutzComment #9
smustgrave commentedWent into #d11readiness in slack
Verified all threads captured and active participants credited.
Comment #11
nicxvan commentedUpdating Credit