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/3072760`
➤*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: Gabor Hojtsy (he/him)

0️⃣ Who is here today? Comment in the thread below to introduce yourself.

mixologic Mixologic, here from the DA
Gabor Hojtsy (he/him) Gábor, core committer
greg.1.anderson Greg Anderson from Pantheon actually in another meeting so half lurking
Alona Oneill Alona. Community developer. Taking notes for company blog!
xjm xjm, core release manager
mikelutz Mike, migration sub-system maintainer
Nick Wilde Nick, he/him, Victoria :flag-ca: /T'So-uke lands. Contrib maintainer/interested party
tedbow Ted, Ithaca, NY
valthebald Valery from Bulgaria, usually Sofia, but the Black Sea coast today :slightly_smiling_face:
andypost Andrey, contributor, maintainer if few core modules

1️⃣ Do you have suggested topics you are looking to discuss? Post in this thread and we’ll open threads for them as appropriate.

xjm Looking for volunteers to help implement detections of non-PHP deprecations for Upgrade Status
xjm (Twig deprecations, deprecated libraries, JS deprecations, etc.)
greg.1.anderson FYI Composer in Core wants to require Composer 1.9.0 as minimum version for Core development. Does not impact non-core use of Drupal.
xjm Min/Max testing status update if anyone has one?
Gabor Hojtsy (he/him) @greg.1.anderson is that an API change (tied to Drupal 9?)
greg.1.anderson We're using a feature of Composer 1.9 to use path repositories instead of the Wikimedia Composer Merge plugin. Our goal is to stop using the Merge Plugin in 8.8 (deprecate it) and remove it for Drupal 9.
mikelutz I’m not sure that this needs its own thread, but <#C6MGDDBPW|mwds> is this weekend. Is there anything we want to focus on?
xjm Yes that's a great topic :slightly_smiling_face:
andypost I'm looking for opinions about module renames - actions and blocker
mixologic I added a topic to the issue, but I dont think it made it here
Gabor Hojtsy (he/him) @mixologic reloaded, will post it :smile:
Gabor Hojtsy (he/him) thanks for the note
Gabor Hojtsy (he/him)
Gabor Hojtsy (he/him) @greg.1.anderson does updating to that change APIs?
greg.1.anderson It does not change any php API
Gabor Hojtsy (he/him) @greg.1.anderson trying to figure out how does it tie to Drupal 9?
greg.1.anderson Few modules use the wikimedia merge plugin, but those that do should switch to path repositories. I guess this change does not affect d9 readiness too much in retrospect
Gabor Hojtsy (he/him) @greg.1.anderson :slightly_smiling_face:

2️⃣ Symfony 4/5 compatibility

Gabor Hojtsy (he/him) @mikelutz worked a bunch more on
Gabor Hojtsy (he/him) almost all fails are around xpath missing form ancestors
mikelutz I did, and there doesn’t appear to be any new issues specific to 4.3 compatibility.
Gabor Hojtsy (he/him) @mikelutz do you know what causes the xpath issues?
mikelutz I’m working on the xpath thing now, but it’s related to changes in symfony/dom-crawler between 4.2 and 4.3. Core doesn’t explicitly require dom-crawler, it’s a dependency of symfony/browser-kit, which is a dependency of mink.
mikelutz But you can get the problematic version of dom-crawler on 8.8 right now if you do a composer upgrade on php 7.1+
mikelutz So, I opened an issue for it here:
mikelutz But it’s already part of the min/max test failures here: along with
mikelutz So, short term for D8 we could fix the dom-crawler by conflicting with dom-crawler > 4.3, but I still need to figure out where the error is and either update our tests or fix the bug in symfony, if that’s what it is.

@markmangoba has joined the channel

3️⃣ Contrib deprecation testing on

Gabor Hojtsy (he/him) @mixologic has these running now with results at :slightly_smiling_face:
Gabor Hojtsy (he/him) I grabbed the data and did some analysis which resulted in :slightly_smiling_face:
mixologic I need to make sure that the projects and branches it is running are actually the ones we want. I believe that its just grabbing the most recent dev version, which might not necessarily be the supported version
Gabor Hojtsy (he/him) also :slightly_smiling_face:
Gabor Hojtsy (he/him) @mixologic would this be the reason the entity project gets the wrong version? :slightly_smiling_face:
mixologic yes, Im sure.
mixologic I'm also not sure that the entity project actually has as much usage as it does
Gabor Hojtsy (he/him) yeah I don’t know how it ended up there, I pulled the D8 usage info
mglaman Entity module has some strong usage, as its a Commerce dependency and others use it for custom entities
mglaman but it does seem to stick to 0.x branch vs 1.x

4️⃣ Examples module Drupal 9 compatibility

Gabor Hojtsy (he/him) @andypost ran a sprint last week on this woot!
Gabor Hojtsy (he/him) See
Gabor Hojtsy (he/him) there is still a bunch of issues to review there if someone is interested :slightly_smiling_face:
Gabor Hojtsy (he/him) @valthebald has been doing a bunch of reviewing and committing there, thanks!
andypost Yep, it needs to fix 2 issues and few of cleanups
andypost But main question is how to provide example of core compatibility
andypost I'd marked 8.8 issues as postponed but there releases not useful
Gabor Hojtsy (he/him) @andypost I think as long as it is compatible with supported core versions, it should be fine
Gabor Hojtsy (he/him) @andypost should not work on 8.8 deprecated things UNLESS the identified ones have introduced replacement APIs earlier
Mile23 Examples has historically targeted the latest stable, so not 8.8.x. But under new management now. :slightly_smiling_face:
Gabor Hojtsy (he/him) haha :smile:
Gabor Hojtsy (he/him) latest stable is also fine :smile:
andypost @Mile23 btw simpletest issue probably needs you to approve
valthebald @Mile23 old management is totally welcome :smile:

5️⃣ Module Upgrader Drupal 9 compatibility

Gabor Hojtsy (he/him) main issue at
Gabor Hojtsy (he/him) @joshi.rohit100 and @amitgoyal have been looking at this
Gabor Hojtsy (he/him) thanks for the patches and test scenario :slightly_smiling_face:
Gabor Hojtsy (he/him) more help is needed there, especially to make the module pass its branch tests first :smile: so we can commit these fixes
Gabor Hojtsy (he/him) and then there is more transformations to fix, eg. drupal_set_message()
Gabor Hojtsy (he/him) and I think db_* will need new transformations and/or existing transformations fixed
andypost I'm following which disruptive a bit in this area
Gabor Hojtsy (he/him) @andypost hm, what is it disrupting?
andypost Compatibility with a wide range of drush9 releases
Gabor Hojtsy (he/him) it makes the module less compatible?
andypost Very probably because not every drush release compatible with every core one, but that's mostly about how checker resolves dependencies
andypost Maybe dmu should be composer plugin in d9
andypost Also here's alternative
Gabor Hojtsy (he/him) @andypost yeah that would need to reimplement the D7 to D8/D9 transformations
Gabor Hojtsy (he/him) until we have people standing up to do it, we should keep the existing one work :smile:

6️⃣ Deprecation cleanup status - blockers to Drupal 9 branch opening.

Gabor Hojtsy (he/him)
Gabor Hojtsy (he/him) there are 13 children issues open, most of them need reviews

7️⃣ Twig 2 upgrade guide and automation; other frontend deprecations tooling

Gabor Hojtsy (he/him) @bnjmnm wrote up
Gabor Hojtsy (he/him) we do not yet have any automated checking for twig 2 things, @lauriii posted some recommendations for potential 3rd party tools to integrate at
Gabor Hojtsy (he/him) anyone wants to run with this?
Gabor Hojtsy (he/him) also there are other frontend deprecations (libraries and JS deprecation) we need to build tooling around
Gabor Hojtsy (he/him)
Gabor Hojtsy (he/him) (JS issue does not even seem to exist)
xjm Yeah it needs to be rubber-stamped first :slightly_smiling_face:
mixologic Also, please coordinate with me if there's something that needs fixing/adding to the testbots to facilitate this.
Gabor Hojtsy (he/him) we hope to eventually implement them in phpstan-drupal or so
Gabor Hojtsy (he/him) so it should be trickling down by itself ideally

8️⃣ Mix/max version testing for dependencies

Gabor Hojtsy (he/him) As we are talking about Symfony 3/4/5 and Twig 1/2 and other dependency versions we need to look at various versions at once ideally, is becoming increasingly more important.
mixologic ^ thats not the issue we want to promote for min/max testing.
mikelutz I can’t speak towards progress on the d.o front, but I have been keeping up with the current vendor issues, and there are two outstanding currently that cause test failures running a composer upgrade on php 7.1+
mikelutz Is a straightforward new deprecation to skip
mikelutz Is currently the bane of my existence, as I have yet to isolate the issue.

Mile23: Just to point out that I'm burned out on looking at simpletest, so if anyone cares whether it's properly deprecated they should start doing stuff.

Gabor Hojtsy (he/him) Thanks for bringing it here in the first place and for calling for help (again)!
Gabor Hojtsy (he/him) :hugs:

9️⃣ Midwest Developer Summit is this weekend with various key Drupal 9 people there in person. Anything we should focus on?

xjm We should definitely discuss, in detail, all the impacts on d.o of the multiple branch compatibility
mixologic Yes, that was the :keycap_ten: next
xjm I mean at MWDS this is my top priority :slightly_smiling_face:
mixologic Great. we can probably get a lot done there.
xjm And I'd also like to encourage sprinting on the things we identified above for upgrade status
xjm It sounds like the min/max testing might be a good secondary convo topic

🔟 Semantic versioning for contrib projects

mixologic Now that we've come to a path forward for how we plan on supporting semver in core (core key using semver + composer.json for advanced features), The DA is planning on auditing our infra to start implementing semver
mixologic Which we'll definitely be sprinting on at MWDS
Gabor Hojtsy (he/him) WOHOO

1️⃣ 1️⃣ *New* Drupal 8.8 deprecations that may need to be backported

Gabor Hojtsy (he/him) @mixologic and I did some analysis on deprecations in contrib that are new in Drupal 8.8
mixologic I had meant to open an issue in the core queue for that.
Gabor Hojtsy (he/him) as per 17% of all contrib deprecated API use now is from either code deprecated in 8.7 or 8.8
Gabor Hojtsy (he/him) most of it is for 8.8 (4% for 8.7 I think and 13% for 8.8)
Gabor Hojtsy (he/him) so @mixologic looked at the toplist of those deprecations and categorized them based on whether the replacements are also introduced in 8.8 or earlier
Gabor Hojtsy (he/him)
Gabor Hojtsy (he/him) this is his analysis
mixologic I would love to get release manager thoughts on deprecation backports: @xjm ?
Gabor Hojtsy (he/him) so looks like there are 9 issues that may be candidates for backporting the new APIs so we can make it possible for people to not need to branch for Drupal 9
mixologic Both existing and new ones.
xjm What does "deprecation backports" mean?
xjm As in actually backporting deprecations to previous minors? That doesn't work for two reasons: (1) Requires the API be added in the old minor as well which violates semver (2) deprecations themselves are a disruptive change
xjm What we can consider doing is being more restrictive about new deprecations in 8.8 starting right now
mixologic So, as we deprecate new things in d8.8, contrib maintainers are not able to simultaneously have a module that removes those deprecations and still have a module that is compatible with the security supported version of core
xjm Yep, that's the way it is
mixologic So the suggestion was that if a deprecation is introduced in 8.8, then we backport the new api, but not the deprecation messages itself.
xjm We're not backporting new APIs to 8.7 and 8.6
mixologic just 8.7.
xjm Nope, not doing that
xjm It breaks semver.
mixologic Im not sure I follow
xjm Introducing a new API in (say) 8.7.7 violates semver
xjm And can have other disruptivbe impacts
xjm So no, we're not going to do that
xjm What we can do is start deprecating for removal in 10.0.0 instead.
xjm Especially if there's a lot of stuff.
mixologic Because if a module then leverages the new api (say, to elminate its deprecated useage in 8.8, it wont be compatible with 8.7.6) ?
xjm Correct
xjm We've always had this concern; it's just people are more antsy now (understandably) about a moving target
xjm So the solution is to stop the target from moving by deprecating for removal by 10.0.0 instead of 9.0.0, rather than to violate semver
mixologic Hmm. what about the plan to backport this:
mixologic is that more of an exception due to its nature?
xjm That's being granted a specific exception for that issue only
xjm Because of the nature of the issue, its criticality, and its impact on the upgrade path
xjm And it's internal API rather than public API
Gabor Hojtsy (he/him) of the top 30 modules, the modules that have over 20 deprecated APIs used that were deprecated in 8.8 are: metatag, paragraphs, webform, google analytics
Gabor Hojtsy (he/him) so at least those very popular modules are in danger of needing a 9.x branch or have a whole bunch of workaround code
mixologic so, sites using those modules wont be able to upgrade to 9.0 until 9.1 essentially, unless the mainters branch
mixologic or yeah, workaround code.
xjm This is also what 8.9 is for
Gabor Hojtsy (he/him) yeah if they drop support for 8.7
xjm They won't be able to have a version compatible with 8.8 and 9.0 at the same time already as of today. However, their 8.9 and 9.0 version will be fine.
mixologic Oh, right. materially it doesnt matter if they're on 9.0 because they can still upgrade to 8.9, which is feature identical
xjm Yep. The main issue is just around allowing modules to be "done" now, and whether we're still adding too many new deprecations between now and Oct. 14.
xjm Contrib already has this problem anyway; it was the #1 pushback to extending security coverage to the old minor
xjm Balancing the old minor compatibility with incoming deprecations
mixologic Right, any deprecations we add between now and oct 14th means they cant be 'done' until 9.0 is released.
Gabor Hojtsy (he/him) unless they drop 8.7 support? then they can work with 8.8 and 8.9 :slightly_smiling_face:
xjm Well, no, that's not what it means
xjm IT means what Gábor said :slightly_smiling_face:
mixologic right, but fwiremember, berdir was saying that dropping 8.7 support in contrib essentially nullify's the idea that we have extended security support
xjm They have three choices (a) Drop compatibility for 8.7 as of 8.8's release date, which is up to them as maintainers (b) Create a new branch compatible with 8.8-plus and remove the newew deprecations there (c) Not do anything until later when 8.9 and 9.0 are under development.
xjm @mixologic It's up to the individual maintainer which they want to do, but they're contrib maintainers; we can't force them to do anything :slightly_smiling_face:
mixologic In any case, the purpose of 8.9 just locked into focus for me, and I see now that "d9" isnt a hard deadline for contrib maintainers isasmuch as a six month overlap where they have an opportunity to upgrade their modules.
xjm It's also super easy for them to create a second branch if they want to, especially now that the core compatibility key will respect semver :slightly_smiling_face:
mixologic Sure we cant force contrib to do extended security support, but maintainers of popular projects recognize that they kinda need to if it is to have real meaning.
xjm Core doesn't even let you know yet that those security backports are available, so we don't need to worry about it
xjm What we do need to worry about is whether the "moving target" is too much of a burden before Oct. 14, and if so, whether other committers will be comfortable with stopping new 8.8 deprecations aside from things that aren't strategic priorities for D9 itself (like dependency-related deprecations)
xjm We're about 2/3 of the way through 8.8's development cycle now
xjm So it might be a good time to switch to "New deprecations should deprecate for removal in 10.0.0, except with release manager signoff"
mixologic okay, so to summarize, We're not backporting API's, that carries far too much semver breaking risk. If a contrib maintainer has usages of code that was deprecated in 8.8.x, and they want their module to be 9.x compatible _on the day that 9.0 comes out_, they can 1. do internal version checking 2. open another branch 3. wait until 9.1 to be 100% compatible with all supported versions or 4. Drop support for 8.7.x
Gabor Hojtsy (he/him) yeah
mixologic And waiting until 9.1 really means, as soon as 9.0 is released, you can fix everything because 8.8/9.0 have all the api's you need.
mixologic and you dont have to worry about supporting 8.7.x anymore
Gabor Hojtsy (he/him) I will try to update my script sometime to more accurately figure out the actual 8.8 deprecations (that do not have 8.7 replacements)
mikelutz It’s not like you don’t have a release or version that works with 8.7 anyway, If you can specify a core semver requirement in info.yml. Really, you shouldn’t be targeting new features to the security supported branch anyway. I wish it was just easier for the average maintainer to understand and manage.
mixologic yeah, I mean the issue is if they update their core semver requirement in info.yml to be higher than the security supported version, and then a grave issue is discovered with their module, and an 8.7.x site relies on that module, does that mean in order to get the security fix, that site owners have to upgrade?
mixologic I guess thats one of those things that is probably rare enough, and will be made moot by having contrib semver that we could probably just roll a BC compatible patch if that happened.
mikelutz Yeah, the security issues is the hangup, and yeah, contrib semver would solve it.
mikelutz Then it would be a matter of release management instead of branch management.
xjm @mixologic No one needs to wait until 9.1 for anything. 8.8, 8.9, _and_ 9.0 will have the same minimum API.
mixologic yeah, vocab collision between 'wait for 9.1.x to open' vs 9.0 is out.
mixologic
xjm 9.1 opens before 9.0 is out
xjm so best not to confuse those things :slightly_smiling_face:
xjm It might open in January depending on how things are going
mixologic yeah, true.
mixologic but really, on the day that 9.0 comes out, a module can cut a release that is 9.0 compatible without regard to BC conflicts.
mixologic (given a module that has 8.8.x deprecations)

1️⃣ 2️⃣ Renaming core modules, eg. actions

Gabor Hojtsy (he/him) @andypost suggested this but I am not sure the related issue he posted was right(?)
andypost There's meta about renames, looks it's part of
andypost The list
- actions => actions_ui
- simpletest (ui)
Needs sub-issue:
- block -> rename to block_ui (needs sub-issue)
- settings_tray/toolbar (maybe create new module)
xjm Before we jump on doing these, we also need a process for deprecating core modules, including both process-process and actual technical ways of marking an entire module as deprecated for all our misc tooling.
xjm So renames is like a sub-item of straight-up removals
mixologic Speaking of tooling, I really think we need to examine this:
mixologic Basically, renaming modules can have impacts on other modules that declare a dependency on those modules.
andypost Is there agreement on removals? I mean about this process? because for example field_layout "hangs" long enough
mixologic And so we need some way to prove that a rename doesnt break contrib modules.
mixologic I.e. the problem is that a module name is essentially an API.
mixologic So, yeah, we need to explore how we actually remove/rename modules.
mixologic (and *also* when we move them into core from contrib, super pretty please rename them)
andypost then removal policy looks low hanging
mikelutz It really seems like we need to deprecate the old module and have the new one next to it in 8.8, along with code to prevent both from being installed at the same time ala content_moderation and workspaces
mikelutz Just reading what I just wrote makes me uncomfortable…
mixologic yeah, that'd still be somewhat problematic
Gabor Hojtsy (he/him) I would personally say these are too cosmetic to be worth the pain for Drupal 9
Gabor Hojtsy (he/him) other than the names not being perfect, there is nothing wrong with them, right?
mixologic because drupal's internal dependency checking doesnt have anything useful like composer's 'replace' we'd have to replicate something to say 'if you have a dependency on actions, then actions_ui fullfils that dependency'
mikelutz hmm, very true.
mikelutz It might just be too late in the cycle to try and manage it.
mikelutz We might need to spend the first cycle or two of D9 putting in place the systems we would need to manage it properly, and then making the change around 9.3 or 9.4
mikelutz Do it right.

1️⃣ 3️⃣ Thanks all for coming. This is it for our meeting, the next one is on August 19th, see

Comments

Gábor Hojtsy created an issue. See original summary.

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented
Issue summary: View changes

Fix URL

Mixologic’s picture

Mixologic
He/Him/His
Primary language English
Location Portland, OR
commented
Issue summary: View changes

Gábor Hojtsy credited Mile23.

Gábor Hojtsy credited NickWilde.

Gábor Hojtsy credited alonaoneill.

Gábor Hojtsy credited andypost.

Gábor Hojtsy credited greg.1.anderson.

Gábor Hojtsy credited mikelutz.

Gábor Hojtsy credited mlhess.

Gábor Hojtsy credited tedbow.

Gábor Hojtsy credited valthebald.

Gábor Hojtsy credited xjm.

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented
Issue summary: View changes
Status: Active » Fixed

Posted logs. Special thanks to @mlhess for access to logs.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

Version: 9.x-dev » 9.0.x-dev

The 9.0.x branch will open for development soon, and the placeholder 9.x branch should no longer be used. Only issues that require a new major version should be filed against 9.0.x (for example, removing deprecated code or updating dependency major versions). New developments and disruptive changes that are allowed in a minor version should be filed against 8.9.x, and significant new features will be moved to 9.1.x at committer discretion. For more information see the Allowed changes during the Drupal 8 and 9 release cycles and the Drupal 9.0.0 release plan.