Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Meeting will happen in #d9readiness on drupal.slack.com.
Hello and welcome to this Drupal 9 readiness meeting!
This meeting:
➤ Is for core and contributed project developers as well as people who have integrations and services related to core. Site developers who want to stay in the know to keep up-to-date for the easiest Drupal 9 upgrade of their sites are also welcome.
➤ Usually happens every other Monday at 18:00 UTC.
➤ Is done over chat.
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to: `https://www.drupal.org/project/drupal/issues/3066478`
➤*Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.Moderated By: mikelutz
0️⃣ Who is here today? Comment in the thread below to introduce yourself.
| tedbow | :ocean: Ted from Ithaca, NY, USA |
| greg.1.anderson | Greg from SF CA USA |
| Alona Oneill | Alona. San Francisco, CA, USA |
| valthebald | Valery from Sofia, Bulgaria |
| catch | Nat. From the UK. |
| mikelutz | Mike, guest moderator. :slightly_smiling_face: |
| Nick Wilde | Nick, he/him, Victoria BC :flag-ca: /T'So-uke lands. Contrib maintainer/keeping an eye on things for work/interested party |
| mixologic | Ryan, Portland, OR Drupal Association. |
| berdir | Sascha, Switzerland. partially here, might have to leave early |
| drumm | Neil, Brooklyn, NY, USA Drupal Association |
| Gabor Hojtsy (he/him) | Gábor, core comitter catching up late -- thanks @mikelutz for running the meeting! |
1️⃣ Do you have suggested topics you are looking to discuss? Post in this thread and we’ll open threads for them as appropriate.
| catch | Maybe or fold it into the schema one. |
| mikelutz | Yes, I think that falls under 3️⃣ . I added the issue link to the thread. |
| valthebald | Examples module for D9 is looking for maintainer(s) |
| andypost | I'd like to pay attention on module renames (actions and menu) - right now 2 blockers need help - - |
2️⃣ Multiple branch compatibility, semantic versioning, and composer.json proposal
| mikelutz | @xjm Correct me if I’m wrong, but these all seemed intertwined into the same topic. |
| mikelutz | |
| tedbow | I have looking at these issues. It seems if we fix #2313917 then it solve the *immediate* problem with 2641658 |
| tedbow | b/c you won’t need to do `- drupal:system (>= 8.1)` because `core` key could handle this |
| tedbow | I am not sure what are time frame for having contrib modules support semver but obviously we would need 2641658 for that. |
| mixologic | From a perspective Contrib modules supporting semver has been blocked on core supporting it. |
| tedbow | if we actually did before contrib semver would ever need info dependencies in info yml to support semver. because if at that point we could rely on composer.json we won’t handle this ourselves |
| mixologic | I think you're missing a word in that last statement |
| tedbow | @mixologic yes, mean to be question “would we ever need?” |
| mixologic | No, I dont think we would need the info.yml dependencies to support semver. |
| mixologic | Unless we're concerned about the small amount of overlap where both would be acceptable |
| mixologic | (dependencies in both info.yml and composer.json) |
| tedbow | ok but 3005229 still needs Framework and Release Manager reviews. |
| tedbow | so info files for dependencies *might* not be deprecated |
| mixologic | Sure. I think is a good, low hanging fruit kind of step that solves one problem well in the interim, even if it might or might not be replaced by composer.json later. |
| tedbow | ok |
| tedbow | 1 thought I had is that right now for our `dependencies` we combine the project name and version constraint - `mymodule (>2.x)` which means we have to parse it ourselves not rely on yml. what if we introduces a new optional yml dependency format. |
| tedbow | `- "mymodule": ">2.x"` |
| tedbow | and if you used this new format it is composer format not our Drupal specific one? |
| tedbow | this would make the migration to `composer.josn` easier |
| tedbow | so if you use new format we would pass it directly to `\Composer\Semver\Semver::satisfies()` |
| mixologic | so, split the dependency from its constraints? Im not sure what that really gets us beyond saving the parsing step |
| tedbow | well. if we documented that *if* you use this new format it will be evaluted directly by `\Composer\Semver\Semver::satisfies()` it would |
| tedbow | because we basically won’t parse it all |
| mixologic | I think the issue is that composer does okay with 8.x by itself, but it doesnt know what to do with 8.x-1.0 |
| tedbow | are we talking about contrib dependencies? |
| mixologic | so we have to parse in order to strip out the extraneous `8.x-` for the contrib deps |
| mixologic | Yes, I was |
| tedbow | what if we stripped in out from “VERSION” instead of the module it is depending on? |
| tedbow | I guess I am thinking of core now not `project_composer` |
| mixologic | Im not sure I understand what you mean on that last comment |
| tedbow | so to not allow … |
| tedbow | `- "mymodule": ">8.x-2.x"` |
| tedbow | only |
| tedbow | `- "mymodule": ">2.x"` |
| tedbow | in info `dependencies` |
| tedbow | would that allow us not to have to parse |
| mixologic | ah for the 'newer' style. |
| tedbow | yeah if having the “newer” style would not just be too confusing for devs. because it would use the same key |
| tedbow | basically the idea was if you want semver support use the newer style. old eventually deprecated(or info.ym deprecated) |
| tedbow | part of my worry is here - |
| tedbow | if we do this it will start to make *some* composer strings work in `dependencies` which could the update script in much harder |
| mixologic | Im not sure it makes it much harder.. those would just be straight copies to the composer.json |
| tedbow | well but you have figure if they meant to use composer or the old style. Currently *only* the old style is supported
I am not a composer expert. are there any strings that would mean something different in our Drupal specific version and composer format? |
| mixologic | no, not really |
| mixologic | The only thing we do differently is stick the major version in our contrib version strings. |
| mixologic | Which we'll hopefully stop doing, and just use semver as our contrib version strings. |
| mixologic | (and there was a short time we had a weird notion of a release state called "unstable") |
| mixologic | Which I think only the rules module ever used. |
| mixologic | (it was some weird state between 'dev' and 'alpha') |
| mixologic | Really the major problematic difference when we talk about the difference between drupal and composer isnt the version strings, or the constraint specifiers, its the divide between what is a 'package' and what is a 'dependency'. |
| mixologic | Composer expects a 1:1 mapping between packages and dependencies. |
| mixologic | Drupal puts multiple dependencies (modules) into one package (projects). |
| tedbow | but there are current strings such as `^2.4` that our current parser doesn’t *support* but also doesn’t through an error. I wanted to post a *test-only* patch for the becaause not all the tests will pass(as they did with the changes). So if you just copied the values in the update script and moved them to composer so sites would different modules enabled |
| tedbow | if some reason they were using them. I think `2.4.*` is another example |
| tedbow | So also if we did this 8.8.0 then sites still on 8.7.0 would act differently |
| tedbow | I am just trying to a bit paranoid here b/c of patch releases that have a caused upgrade problems |
| mixologic | yeah, I hear that. So, I guess what Im trying to sort out is what kind of "different" they would have. |
| mixologic | Basically it would _expand_ the potential list of modules that could be enabled. |
| mixologic | Which to me doesnt seem BC breaking, and is more in line with 'feature addition'. Everything that worked before would continue to work. |
| mixologic | If, somehow it made it so that a module that was able to be enabled under the old regime can no longer be enabled, thats definitely a break. |
| tedbow | well except if you had deployment script with something like demostrated in this test
`$composer_wildcard_constraint = new Constraint(‘2.4.*’, ‘8.x’); $tests[‘(2.4.*)-2.4.2’] = [$composer_wildcard_constraint, ‘2.4.2’, TRUE];` |
| tedbow | this passes with 3004459 but not now. so as soon as you update to 8.8.0 your script would enable a module it didn’t before |
| catch | I'd really like to see land in 8.8.x so that contrib modules can start supporting Drupal 9 as soon as the branch opens fwiw. |
| mixologic | AFAIC, is ready for RTBC basically. |
| mixologic | actually, only kinda |
| tedbow | I think we need a couple other tests. basically not if you have value in `core` that is not supported and is not valid. your site will just say it can’t be enabled |
| tedbow | right now with 2313917 it would crash the modules page. but that should be easy to fix |
| tedbow | I will add a test for this |
| mixologic | Yeah, we also should test changing the core version and having some ^8 | ^9 modules etc |
| mixologic | verifying that if core is 9, that those constraints still match. |
| mixologic | so, one thing that I wish we had more data on... |
| mixologic | I have a *very* strong hunch that the number of users that have contraints in their dependencies in their custom modules is a number approaching zero. |
| tedbow | hmmm. I could see where that hunch would come from but also something by the nature of it, I don’t think we can get data on |
| mixologic | Because custom module dependency management would only really be something necessary in an environment where that custom module is being reused on many other sites. |
| mixologic | So, maybe in a university setting or the like |
| tedbow | well but won’t there a lot of custom modules that would be dependent on at least `>=` against a contrib module |
| mixologic | But then constraints are usually to work around a specific bug, or express a specific branch of a contrib module. Its really, really, really rare for there to be more than one constraint. |
| tedbow | but would the fact that there would be only 1 constraint in custom modules matter? |
| tedbow | if zero I could see it mattering |
| mixologic | Im just mentioning the risk factor.. as in some of what 'works now' might support some potential situations, that in reality are very unlikely to have ever manifested. |
| mixologic | If a BC break happens in the forest and nobody is around to hear it, did it really happen? |
| tedbow | I have feeling I will hear about it :stuck_out_tongue_winking_eye: |
| mixologic | Thats a very real possibility. |
| mixologic | But, that also brings up another thing about our current constraints. |
| mixologic | The very worst possible constraint you can do is unbounded `>` or `>=` |
| mixologic | Which is what a lot of contrib does, because of history |
| tedbow | because now it is an implied <9.0-dev? |
| mixologic | well, no, I mean for other contrib modules. |
| mixologic | for example `webform:webform (>=8.x-5.x)` |
| mixologic | if your module provided built in webforms and the 6.x branch of webforms is a complete rewrite, thats dangerous |
| mixologic | Older drupal assumptions about module compatibity were such that you could somewhat sorta expect newer branches to be compatible with older branches. |
| mixologic | Except reality has also shown that assumption to not be the case. |
| tedbow | yes but you could make the same mistake in composer correct? `>5.x`
but I guess `~` `^` make that easier to avoid |
| mixologic | So, the composer facade seatbelts those unbounded constraints by changing them to be `^'s` instead of `>'s` |
| tedbow | this makes me think we *should* do the new format I mentioned earlier like `- “webform:webform”: “^5" my worry with is that it allows some composer string to be use directly but *not all*. So it could be very confusing |
| mixologic | yes, you can make that mistake in composer, but all their docs have steered people away from it, and its generally known to be bad practice and you really better _know what you're doing_ and better _really mean it_ if your using an unbounded constraint. But way, way too many of the dependency specifications in drupal are already this way. |
| tedbow | yeah but seems like something we can’t auto fix for people in core because I am sure there are some contrib or custom modules relying on this. espcailly if your module does something super simple like form alter that didn’t actually change when a new major version of the module your module is depending on was released |
3️⃣ Schema version and database updates hooks in Drupal 9.
| mikelutz | sponsored by @mixologic :slightly_smiling_face: |
| mikelutz | from @andypost |
| mikelutz | Seems relevant here as well, per @catch |
| mixologic | So my question here is that `CORE_MINIMUM_SCHEMA_VERSION` is what determines whether or not an update hook is going to fire. |
| mixologic | Are there contrib modules that have update hooks that are expected to run in order to be "installed" ? or is that atypical and that most maintainers update their schema numbers such that all the installation procudures happen properly, and you really only need the update hooks if you're actually updating? |
| drumm | That’s atypical. Installing doesn’t fire update hooks and sets the schema version to be whatever the latest update hook is. |
| mikelutz | @mixologic update hooks don’t run on module install. The module’s schema version is set to the largest update hook on install, and on updates, only hooks above that are ran. |
| mikelutz | Now a good question is how long do we keep 8xxx hooks around. They will definitely be needed to update to D9, but do we make people update to 8.last first, and fire all of those updates before allowing them to update to D9 and start the 9xxx series of hooks? |
| drumm | Someone could call whatever they want, including an update, inside their hook_install() implementation. That’s probably a bad idea, but doesn’t get any special bookkeeping or anything either way, it is just implementing a hook. |
| mixologic | Okay, so a d8 module that is fully compatible with d9 could install on d9, and in theory should have the proper schema without running the update hooks. Anything contrary to that notion is an exception, and problematic, and not something we can support very well. |
| mixologic | What about this scenario: user has a module installed. a new update for that module comes out with update hook `8001` if they upgrade to d9 without first upgrading their module, they wont be able to run that update hook (presuming that we set the minimum schema to 9000) |
| drumm | If they can implement updates that run on both the original 8.x version and without deprecations on 9, they can be lenient about updates running on 8 or waiting until 9. |
| mikelutz | Essentially, if we set the minimum to 9000, then that means we require you update to 8.lts before updating to D9. (how that works practically, I’m not certain) |
| mikelutz | especially with contrib who won’t have LTSs. |
| mikelutz | So, I think for now, at least we need to leave the minimum at 8000 for the sake of running updates, or have some special handling for when you are running the D9 codebase with a 8xxx schema to force an update before your site works, or something like that. |
| drumm | There used to be a way for contrib modules to say what they required to do an update. |
| drumm | not sure if it was ever well-used much in contrib |
| drumm | And it still exists |
| mikelutz | huh, I don’t think I have ever used that hook. |
| andypost | Yep, but entity schema is remaining question here |
| andypost | I mean |
| catch | I think we need to ditch Drupal minimum schema version entirely, and rely on hook_update_last_removed() |
| catch | If we add semantic versioning for contrib modules, they could start with a 1.0.x branch and hook_update_1000() |
| mikelutz | Well that sounds terrifying, lol. |
| mikelutz | Might be time to change the name of the hook at that point, if not come up with a different approach towards managing version schema and db updates. |
| drumm | When I originally created hook_update_N(), I never planned on N being meaningful other than always increasing. It just happened that it didn’t need to be sequential, so people started giving it meaning. |
| catch | Well that's also true but at least I think we need to leave minimum schema version at 8.x until we do something like that. |
| mikelutz | I feel like, given everything that has to happen in Drupal 9, just leaving the 8xxx update hooks in there, and supporting the updates through the 8xxx and 9xxx is best for D9. I think we should target replacing the system as part of d10, as hook_update_10000+ might get a bit confusing as we jump into 2 digit majors. |
| catch | Well I do think we should drop old core updates but that only needs hook_update_last_removed() (and test updates). However it's not blocking anything just good cleanup. |
| drumm | A cheap hack would be parsing out underscores, so hook_update_1_0_0_00 == hook_update_10000, but that’s probably too clever. |
| mikelutz | What does last_removed do if it finds that you need an update function that no longer exists? |
| drumm | |
| fgm | @drumm The hook_update_MAJOR_MINOR_PATH() path is exactly what I’ve been thinking for some time. Why do you think it’s “too clever” ? |
| drumm | Giving those numbers implicit meaning is already a bit of a clever hack. If either minor or patch numbers are 2 digits, that’ll ruin it. |
| fgm | not unless the ordering ceases to be a simple number comparison, but performs semver comparisons ? |
| andypost | IIRC there was discussion to keep some 8.x parts until 9.1 so it could give a way to announce it from reports/status |
4️⃣ Porting contrib DB drivers to Drupal 9
| mikelutz | By @fgm re: MongoDB suite |
| andypost | Sqlserver looks maintained |
| andypost | Btw there's a question of "mysql split" @alexpott used to hack on it |
| fgm | argh I misssed the chat |
| mikelutz | @fgm Feel free to continue it. These threads will be used for latecomers for the next day or so. |
| andypost | I found the link) |
| fgm | For the record, mongodb 8.x-1.x (the broken legacy chx version) works as a database driver and, while it remained unchanged on d.o. since 2015, another developer essentially upgraded it on its own to work on current versions and fix lots of bugs, and it might come back for maintenance on d.o., but AIUI it needs a significant core patch. Version 8.x-2.x is unrelated and does not expose mongodb as a database |
| andypost | Actually this one |
5️⃣ Deprecation cleanup status - blockers to D9 branch opening.
| valthebald | @mikelutz do you mind to change the heading to 6️⃣ ? :slightly_smiling_face: |
| mikelutz | @valthebald We have an agenda, if you have something to add, would you mind adding it to 1️⃣ , and I’ll open a thread for it at the end? |
| valthebald | oh sure |
| valthebald | moment |
| mikelutz | |
| mikelutz | We are down to 144 (30) unique deprecation errors that aren’t postponed on the D9 branch opening. |
| mikelutz | Some of them are methods marked deprecated that are actually BC shim code, and should probably just be @internal, with follow-ups to remove in D9. |
| mikelutz | I filed to see if we want to discuss standardizing in-code documentation for BC shims, to make it easier to find and remove this code when opening a new major version. |
| mixologic | worked out a design for how to get the deprecation tests running on contrib regularly today. will be implementing soon. |
6️⃣ Examples module for D9 is looking for maintainer(s)
| valthebald | I've checked the code base, and was chasing the issue queue of the module since the last meeting 2 weeks ago, but haven't talked with @Mile23 yet |
| valthebald | next steps as I see them: - what are the main pain points - what is Paul's availability - focus areas? - anyone else interested? It would be much easier |
| Mile23 | pain points are that I don't want to be a maintainer any more. :slightly_smiling_face: My availability is whatever we can do to help someone else be the maintainer. |
| valthebald | What help would the someone in question need, in your opinion? :slightly_smiling_face: |
| Mile23 | I can be around to answer questions and stuff. |
| valthebald | That sounds awesome |
| valthebald | I will continue to look in the issue queue, so if you'd feel I can take the burden at some time, and can be around... |
| andypost | That's great idea to have examples d9-ready |
| Mile23 | @valthebald is now a comaintainer of examples. rock on. :slightly_smiling_face: |
| valthebald | wohoo :rock: |
| Mile23 | I think there's some process where I'm supposed to make an issue about it and then you can be the owner when it's RTBC or something. |
| Mile23 | oh this one... |
| valthebald | that's only if the current maintainer is unavailable I think |
| Mile23 | |
| Mile23 | so much documentation. |
| valthebald | I think it's safe to skip the full flow... |
| valthebald | > If you found a person to be your co-maintainer, you can usually grant them maintainer status without the help of a webmaster |
| valthebald | that's from |
| Mile23 | oh, and there's a twitter account. :slightly_smiling_face: |
| valthebald | :thumbsup: |
| Mile23 | |
| valthebald | I didn't know about this one |
| valthebald | but this is less urgent I guess, more important is make the module d9-ready |
| Mile23 | it's up to date for all the deprecations in 8.7.x, and has a weekly CI run against 8.8.x that I think isn't failing right now. |
| valthebald | awesome! |
| Mile23 | oh wait, I removed the weekly ones because they were failing and sending me emails. |
| Mile23 | anyway... thanks for taking this up. :slightly_smiling_face: |
| valthebald | thanks to you :thank-you: |
| Mile23 | I'm going to go learn how to make you the owner. I think I have to ask drumm or something. |
| Mile23 | but you can pretty much do anything now, and if you have questions just send 'em over. |
| valthebald | Great! |
| andypost | @valthebald sounds this one for phpstan checker |
| valthebald | @andypost thanks |
7️⃣ Is there anything we missed, or that should be brought up in the next meeting?
8️⃣ I missed this, but: Module renames, action and menu blockers.
| mikelutz | |
| mikelutz | |
| mixologic | please please please let me know if there is a module in core planning on being renamed. |
| andypost | @mixologic parent of this blocker renames actions module |
| mixologic | There are contrib projects that have dependencies expressed on `drupal:action` |
| mixologic | not many.. digging |
| mixologic | yeah, about 14 modules |
| andypost | oh, that's because they not upgraded after |
| andypost | but on they also can relay on action entity forms (UI) |
| mixologic | Right, but as far as Im concerned, module names are an API, because other things depend on those names. |
| mixologic | Any site running those modules will have problems if they upgrade right? |
| andypost | I bet composer dependencies and ones should be used to point that module for 8.x specific branch |
| mixologic | right but they arent now. so a module would have to be updated first, otherwise it might get uninstalled because its dependency is no longer satisfied. |
| andypost | hm... out of my head only put this rename info system module's update hooks |
Comments
Comment #2
Gábor HojtsyComment #3
xjmI'd like to talk about multiple core branch compatibility, the
composer.jsonproposal, and core's current critical semantic versioning bugs (#2313917: Core version key in module's .info.yml doesn't respect core semantic versioning and #2641658: Module version dependency in .info.yml is ineffective for patch releases). We need to resolve the critical bugs in Drupal 8 even if we addcomposer.jsonsupport in Drupal 9. @tedbow has a proposal for resolving #2313917: Core version key in module's .info.yml doesn't respect core semantic versioning that I think puts us on a good direction that will work either way, without adding much complexity.Comment #4
MixologicI'd like to talking about how we'll handle database updates, and
const CORE_MINIMUM_SCHEMA_VERSION = 8000;If I have a module, and its compatible with d8 now, and has no deprecations, yet has a few update hooks, say 8001-8004. When d9 comes out, and I make a new release of my module, should I start using 9xxx update hooks? Should the 8001-8004 hooks run if installing this module for the first time on a new d9 site? or do we simply say '8000 is the CORE_MINIMUM_SCHEMA_VERSION from here on out' ? and just increment from there, and assume that db_update hooks should all fire?
Comment #5
andypostSchema issues interesting, mostly in terms that schema still not refactored, see #2908886: Split off schema management out of schema.inc and its parent
Comment #6
fgmI'd like to talk about how I can best port the MongoDB suite to D9, especially now that it seems d.o. CI can instantiate non-standard services like MongoDB, which wasn't the case on the old system and meant I had to to it on github+travis. Is this an appropriate topic ?
Also, for the 8.x-1.x which looks like it might get revived, the database handlers question is relevant too.
Comment #7
mikelutzComment #8
mikelutzComment #17
Gábor HojtsyPosting meeting log. Special thanks to @mikelutz for running the meeting and @mlhess for providing formatted logs.
Comment #18
fgmFWIW, the developer who upgraded/evolved the 8.x-1.x MongoDB database driver is https://www.drupal.org/u/daffie