Comments

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

justafish credited DamienMcKenna.

justafish credited NickWilde.

justafish credited catch.

justafish credited mikelutz.

justafish credited webchick.

justafish credited xjm.

justafish’s picture

justafish
she/her
Primary language English
Location London, UK
commented

Moderated By: gaborhojtsy

Hello and welcome to this Drupal 9 readiness meeting!

This meeting:
➤ Usually happens every other Monday at 20:00 CET / 14:00 ET.
➤ 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/3016213
➤*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.

:zero: Who is here today! Comment in the thread below to introduce yourself and tell us what are here for.

gaborhojtsy Gábor. Interested in refining the master plan especially around versioning and experimental modules, those two seem to be our own requirements that are more up in the air than others.
xjm Hi all. xjm, release manager. D9 is a release so I care about releasing it. :slightly_smiling_face:
Nick Wilde Nick, FT agency dev but here in a personal capacity. Victoria BC :canada: . 75% just monitoring stuff so I know what's coming up/can make sure modules and sites are compatible with future stuff. 25% interested in contributing to said future.
mikelutz Hi all Michael Lutz, Shiny new migrate subsystem maintainer here. :slightly_smiling_face:
catch Nat. The other release manager :slightly_smiling_face:
mixologic Mixologic, drupal infra etc.

0️ The two parts of the plan. I broke down the plan to two parts: (a) the things that should land in 8 https://www.drupal.org/project/drupal/issues/2608062> (b) the things that will primarily land in 9 but should be prepared in 8

gaborhojtsy We are making sure to underline the fact that practically all the things can be worked on right now and they should since the timeline is tight (see more in topic 2:)
gaborhojtsy I removed the 8-8, 8-9 migrations from the requirements altogether since we plan to rely on update.php as the default means on upgrade from 8 to 9.
gaborhojtsy @Mile23 asked on the master issue why are we not deprecating simpletest before Drupal 9?
xjm That's a very good question.
xjm I think the intent has always been to do so, but given the timeline we might not be able to make it a hard blocker.
gaborhojtsy the fact that that is not listed in the plan and other things going on may not be listed is that we are focusing the plan on the must haves :slightly_smiling_face: primarily D9 is driven by the symfony deadline and then some of our own internal requirements :slightly_smiling_face: based on the progress so far it looks likely that simpletest will not be used by that time :slightly_smiling_face:
xjm I'd consider it and the whole phpunit initiative "Should have" (versus "Must have")
xjm Maybe we should add a should-haves section to refine the scope
gaborhojtsy that would be useful yup :slightly_smiling_face:
xjm For me the should-haves would also include things like all experimental modules stable, maybe 8-8 migrations, and so on.
gaborhojtsy the experimentals would be nice to clarify -- @catch wrote that they should be stable or removed or their status clarified
gaborhojtsy it would be great to represent must / should with issue priorities, eg. must as critical
gaborhojtsy I was not sure whether to make meta issues critical or their children, etc.
gaborhojtsy for simpletest itself the countdown looks fabulous even if its not useful for predictions :smile: http://simpletest-countdown.org/
catch I think the question with experimental modules is at what point are we taking the decision.
catch Simpletest I’m assuming we’ll deprecate the moment that hits zero but I wouldn’t make it a hard blocker to 9.x things - obviously it’ll be great to do it though.
catch i.e. are we going to give experimental modules until 9.0.0-alpha1 to get stable?
catch If so, then we could pick the 9.x date without making specific decisions about specific modules, but not add anything new and unstable to 8.x from that point onwards, or something like this.
gaborhojtsy @catch it would certainly be a nice marketing possibility to “ship new things” with D9 that merely get stable then but it could be a slippery slope
xjm (That would be in 8.9 too)
mikelutz @catch It’s basically 8.LTS.alpha1, right? The goal is no experimental modules in the LTS. D9 then gets all sorts of new experimental modules.
xjm (In 9.1+ only)
catch Yes I mis-spoke, it’d be 8.LAST.0-alpha1 for the final logical cut-off.
mikelutz maybe none in 9.0, if that’s purely a deprecation release, but but 9.1 experimental modules would be in, right?
mikelutz @xjm++
xjm Yep!
catch Yes, and possibly something that didn’t make the cut in 8.LAST.x would end up in 9.0.x still
catch So 8.LAST.x - only stable code.
catch 9.0.x - /maybe/ existing stabilising experimental modules removed from 8.LAST.x, assuming they’re on a path to stability still.
catch 9.1.x regular minor release with whatever is lined up.
catch What we avoid is adding brand new experimental code to the 8.LAST.x/9.0.x branch.
xjm We could move this to 2️ since it's relevant
mikelutz So, does that mean a year without new features?
xjm Small features/improvements can still land in 8.9/9.0. Just not experimental unstable things.
xjm (I think anyway; we need to discuss more)

@Mile23 has joined the channel

2️ Timeline! We should be trying for a June 2020 9.0 release, which means a freeze on new experimental stuff less than a year from now at the 8.8 alpha deadline in Oct 2019.

xjm Correction: The last part should say "at the 8.8 alpha deadline"
xjm I think we should make a chart of this
gaborhojtsy Made the correction to the text so its clarified for the notes :slightly_smiling_face:
gaborhojtsy This also means that Drupal 9 should be API complete in less than year, right?
gaborhojtsy if we are shooting for Oct 2019 that would rule out Symfony 5 dependency given that is released later or would that be an extension?
gaborhojtsy extension of timeline for Symfony specifically I mean
xjm No, it's 8.9/9.0 that would need to be S5 compatible. Symfony is maybe worth its own thread to discuss.
mikelutz So, 8.8 is a regular release, 8.9 is the LTS, released at roughly the same time as 9.0?
xjm Yeah
mikelutz Does that make 8.8 the last chance to deprecate apis, or could we still do that in 8.9?
xjm Interesting question
gaborhojtsy 8.8 would ideally be the last if we want to make it possible for modules to be compatible with 8.LAST and 9 on day 1
xjm If we did add deprecations, they would need to be for 10.0.0
xjm Which might be okay
gaborhojtsy yup :slightly_smiling_face:
gaborhojtsy we indeed need to plot these things on a timeline :slightly_smiling_face: here is when you can deprecate things for removal in 9, here is when …. etc :slightly_smiling_face:
catch In one issue i suggested that, deprecate for 10.x, leave room for exceptions for something we really want to force in 9.0.0.
mikelutz Well, that might be an important date to announce then, if 8.8-alpha1 is the last chance to tag something deprecated that you want to rip out before 9.0
gaborhojtsy that will open some eyes :smile:
gaborhojtsy yeah most people still think D9 is in the far future, but nope
mikelutz October 2019, less than a year…
xjm Yep :slightly_smiling_face:
catch @xjm so just to confirm, you are thinking about new experimental code being added to 8.8 (as long as it lands by alpha), but nothing new added to 8.9/9.0 branches. If so that’s how I’ve been thinking about it. Obviously 8.8 stuff could go stable in 8.9 or be removed from the 8.x branch and stabilise in 9.x instead.
xjm We'd remove alphas. Beta modules I think should be left in 8.9/9.0. Ideally we would stabilize them but "should have" vs. "must".
catch hmm interesting I was thinking removing even betas due to not having a further minor release to make, but I guess we can still backport issues to those modules more liberally in 8.9 because they’re still beta.
gaborhojtsy I think its cleaner for someone who (unfortunately) relies on beta/rc modules if they are kept
gaborhojtsy unless we expect they will do some harm / maintenance issues there
catch My feeling was that they could stay on 8.8.x for up to six months then go straight to 9.x, skipping 8.LAST.x
catch I’m only concerned about those modules being in some kind of limbo in 8.LAST.x - i.e. with serious bugs that are fixed in 9.x but not in 8.x because we can’t backport without releasing a minor.
catch i.e. especially if they require a change to stable code in order to become stable, such as workspaces currently does.
xjm I think it's a much bigger break to remove beta Workspaces than to backport a juicious disruptive change to Workspaces
catch But you could update to 9.0.0, and you have six months security overlap to do so.
catch Something like the path alias update I don’t think we want to make an 8.x-LAST-LAST.x release for or put into a patch release.
mikelutz :no_entry_sign: @damienmckenna
damienmckenna Thanks everyone!

3️ Symfony. How aggressively should we target Symfony 5 for 9.0.x?

gaborhojtsy well, if D9 alpha is to be in Oct 2019 that would be before Symfony 5 release date
catch It wouldn't be, it should be about March 2020 no?
mikelutz It would coincide with 8.9-alpha1, not 8.8-alpha1
catch 9.0.0 June 2020, alpha x weeks before that. We night want slightly longer periods than we've been doing for minors.
Nick Wilde Full stable symfony 5.0 release is scheduled for November 2019
gaborhojtsy yeah https://symfony.com/roadmap?version=5.0
Nick Wilde So really I'd be of the opinion that it should be pushed and included as beta for the first alpha and stable for D9-Alpha2+ or whatever exact version.
gaborhojtsy so first we need all the helping hands on the Symfony 4 issues, which we can already work against :slightly_smiling_face:
gaborhojtsy then indeed we do have time to work with Symfony 5 hopefully included in D9 :slightly_smiling_face:
catch Symfony 4 has a green patch passing tests, but it needs the individual changes split of to their own issues and resolved properly. The very positive thing is there are zero significant API changes that affected core between Symfony 3 and 4.
catch So the big thing here is that there should be a Symfony 5 beta/rc around the time we’re planning to branch 9.x, we should be able to jump on it as soon as it’s ready really.
gaborhojtsy yup!

4️ Contrib versions and project dependencies. When discussing the plan @webchick raised that the plans with semantic versioning and even the multi-core compatibility features looks ambitious given all other things. Do we have enough people interested to work on these?

gaborhojtsy @webchick was arguing that it does no harm that contrib needs to branch for D9 and this is a requirement we set up for ourselves that is not anywhere trivial (involving our update system, localizations, etc.)
xjm Angie's case was that people should just create two identical branches of their modules for 8.x-whatevs and 9.x-whatevs. I think this sort of breaks the idea of the continuous upgrade path though.
gaborhojtsy OTOH there are various things about security support messaging across major branches, branch compatibility, etc. that needs to be resolved either way
gaborhojtsy It is true that this is a huge maze of issues and we don’t know if the DA can fund all the work that needs to be done on that side either. /cc @mixologic
gaborhojtsy (Neither are people currently working on the core side)
catch I feel like the core compatibility stuff is much higher priority than semantic versioning - that could come later.
catch i.e. if my 8.x-3.x module can work with 9.0.x then we have a continuous upgrade path.
catch If semantically versioned modules ends up being 9.x only we still have a continuous upgrade path.
gaborhojtsy if others agree, we should clarify #3 in https://www.drupal.org/project/drupal/issues/2608062 then because I worded that misleadingly :smile:
gaborhojtsy > Core compatibility must be enhanced so that the same release of a module can work with both 8.x and 9.x. or semantic versioning must be introduced in contrib (without core compatibility in the version number) and core needs to support it in Drupal 8 and 9.
gaborhojtsy Or maybe that is accurate but it makes it sound like the scope is much bigger than “just” core compatibility, hm.
gaborhojtsy @catch I think our thought experiment concluded that we’d need to touch many of the same parts in core for the first case, eg. make sure locale update works with major version numbers of contrib that does not equal major version of core, etc.
gaborhojtsy same for update module, etc.
gaborhojtsy so either way we need to make core mostly agnostic of a contrib “major compatibility” version number and rely on other info to tell us true compatibility
catch @gaborhojtsy yes there’s a lot of bits that need to work other than simply the module installing and running and that work is likely to be similar.
catch Having said that though, the core compatibility change itself requires work from contrib modules, so needs to be ready with plenty of time for modules to update.
mixologic To clarify semantic versioning, we already support that on http://drupal.org|drupal.org, and it really just means that we allow for an additional patch level.
catch Update status and locale contrib authors shouldn’t have to worry about, that’s completely between core and d.o
xjm @mixologic The big sticking point for module versions is the branch prefix
xjm Stuff should be "2.3.0", not "8.x-2.3.0"
mixologic It can be either
xjm That's a big change for core, the ecosystem, etc.
xjm Oh that already works?
xjm Wow awesome work :slightly_smiling_face: I think that will mitigate @webchick’s concerns
mixologic No, I mean we can easily support both, and should
xjm oh
xjm yes :slightly_smiling_face:
xjm Okay I thought you were saying it was already done, hah
mixologic the 8.x- part isnt useful going forward
mixologic other than as a easily convertable string to ^8
xjm *.d.o needs to be able to usefully present, host, etc. module versions. contrib need a phase where they can do either. And core needs to deprecate the old-style prefixed version numbers once d.o supports both.
gaborhojtsy Yeah but we need to make localize., updates.d.o, etc. ready for that, no?
xjm Yeah
mixologic we do anyhow
webchick I was less advocating for forcing module maintainers to branch (though admittedly that would also be an approach) and more for “flipping” where the logic happens, and building the “this version of core accepts either 8 or 9 modules” into system.module.
webchick And putting a notice on admin/reportd/status that we will stop accepting that evntually.
webchick Because that feels like ~4 lines of change and without a DA dependency. I’m sure I’m missing some cluebats tho
mixologic Yeah, that really eliminates the "smooth" upgrade path by moving it to 9.1 or 9.2 or whenever we "stop accepting that eventually:
webchick Cos between semver for contrib or GitLab, I feel GitLab has way bigger positive community connotations, so would love the DA to spend their time that way
webchick @mixologic No worse than dropping support for PHP5 mid-stream
webchick The smooth upgrade path still exists.
xjm I think it's a lot more than a 4-line change in core
webchick Just you need to plan for future obselence. But that’s basically a permanent thing now.
xjm We have assumptions everywhere.
webchick Yeah, I honestly wanna try writing the patch some evening/weekend and see what happens. :slightly_smiling_face:
webchick So I should get to that about June 2020. :smile:
xjm haha
catch I do think the core compatibility stuff /in core/ is first priority because it allows contrib to specify they’re compatible with 9.x as early as possible.
xjm Yeah, and getting the core part done will flush out the scope for the rest
xjm So maybe we want 8.x-*-type prefixes as one of those hypothetical things we deprecate for 10.0.0 (in 8.9/9.0)
catch Yes I think that would be ideal.
mixologic I strongly advocate against that.
xjm The alternative is to get it done in less than a year
catch You want to require semver for 9.0.0 instead?
mixologic No
mixologic Im saying it will be relatively trivial to allow for both semver *and* prefixes if they exist.
catch hmm, so /never/ deprecate prefixes?
mixologic deprecate them for 10
xjm Yeah so we agree :slightly_smiling_face:
catch OK yeah that’s what xjm said above, and I also agree with that.
mixologic but It wont be sufficient to say 8.x|9.x
mixologic otherwise that *precludes* doing any semver for contrib.
mixologic well, maybe not.
mixologic I suppose that could also be added in later in the 9.x cycle, but then we've got to change things twice.
catch So one thing. Let’s assume we support core compatibility and probably semver in core, but we do not have update status and locale downloads fixed yet - do we still branch 9.x?
catch That would then mean branching with a release blocker in place, which could delay the release, but we’d have 6 months to fix those issues.
gaborhojtsy @catch if we have are other fixes lined up then we don’t need to branch it yet then(?)
mixologic So, the idea with the updates and locale metadata is that we drop, entirely, the 8.x from the url.
mixologic and to do that we have https://updates.drupal.org//release-history/views_slideshow/8.x redirect to https://updates.drupal.org//release-history/views_slideshow
mixologic and it would contain all the release data for 'views_slideshow' for 8.x on up.
catch @gaborhojtsy if we don’t branch, aren’t we delaying the release until the next window?
mixologic For the locale metadata, we would do the same thing.
mixologic because the translations *already* have the complete version in them, we can also drop the 'core api' from the urls.
mixologic ```/files/translations/8.x/views_slideshow/views_slideshow-8.x-4.6.es.po```
gaborhojtsy @catch I think 9 is a special case in that we plan to do most things in 8 (and ahead of the 9 branch opened for things we do on 9), so slightly postponing the branching would not block it from adhering the same alpha date still
catch hmm postponing the branching means that issues that are lined up can’t be committed though.
gaborhojtsy @catch yeah, it would indeed be a hostage situation approach yeah
xjm Yeah I'd be very nervous about not branching
catch I think we probably need to allow for June 2020 to slip to July 2020, to avoid June 2020 slipping to December 2020 tbh.
catch i.e. if we’re confident we can hit June 2020 we branch when we branch.
catch If we’re absolutely in a mess for some reason then we’d know well in advance of then.
gaborhojtsy June 2020 is our date to allow some wiggle room if we are in a huge mess, but we are trying to not be in one by assessing our plans well :smile:
gaborhojtsy @mixologic do you mean we should already be gradually dropping the “superfluous” version info from those (localize) URLs as soon as we can?
mixologic @gaborhojtsy Once we get the redirects in place, yes.
mixologic @gaborhojtsy unless there is some other unknown to me reason why that core api data is in the localize urls....
mixologic @gaborhojtsy I dont actually know how localize works when it comes to translations across release versions..
mixologic @gaborhojtsy can I ask you a couple questions about that outside of this thread?
gaborhojtsy @mixologic absolutely, please :slightly_smiling_face:

5️ We are way overtime now, so thanks all for coming. Will save the notes and follow up on some stuff that is actionable :slightly_smiling_face: Also will bring some to the committer meeting this week.

xjm Thanks @gaborhojtsy!

Next meeting in 2 weeks Dec 10!

justafish’s picture

justafish
she/her
Primary language English
Location London, UK
commented
Status: Active » Fixed
jibran’s picture

jibran
he/him
Primary language Urdu
Location Toronto, Canada
commented

Credited Gábor Hojtsy :)

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.