Hello and welcome to this Drupal 9 readiness meeting!

This meeting:
➤ Usually happens every other Monday at 20:00 CEST / 15:00 ET (for this week).
➤ 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/3007152`
➤*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.

:one: Our master issue is at https://www.drupal.org/project/drupal/issues/3007300. Our other issues are children of this one and form this nice tree: https://www.drupal.org/files/issues/2018-10-26/%5BMETA%5D%20Release%20Drupal%209%20in%202020%20%233007300.pdf We identified a lot of things since the last meeting and will delve into specifics in further agenda items. Any major blockers that we forgot?

:two: Migrate! The team has been working hard to close more multilingual blockers. The outstanding question on supporting Drupal 6 to 9 migrations seems to be resolved with building it in Drupal 8 and deprecating it for removal in Drupal 9 (moving to contrib). The Drupal 8 to 8 (AKA 8 - 9 migration path) was also discussed on the core committer meeting two weeks ago. Alex Bronstein was to post an update on the issue but I don't think he did. Is this accurate? Other major outstanding migrate questions?

:three: Contrib versions and core compatibility.

Further topics TBD

Comments

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

catch’s picture

catch
he/him
Primary language English
commented

Might be good to talk about #2631202: Doctrine no longer supports SimpleAnnotationReader, incorporate a solution into core - i.e. try to figure out what the minimum change we'd need to make for 9.x is.

gábor hojtsy’s picture

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

mikelutz
He/Him
Primary language English
Location Michigan, USA
commented

I snagged the meeting about 3 days after we had it. Here's what I saved, with a little formatting added.

gaborhojtsy [Oct 29th at 3:01 PM] :zero: Who is here today! Comment in the thread below to introduce yourself and tell us what are here for.
gaborhojtsy Gábor Hojtsy, one of 3 core product managers, trying to organize all the things around Drupal 9 preparedness
Nick Wilde Nick Wilde, Victoria BC CA. Keeping abreast of issues to ensure my contrib modules stay working as smoothly as possible - and good to know for work as well.
mixologic Hi there, Mixologic here representing the DA and drupal.org infrastructure services. (edited)
heddn Just here to keep migrate's wheels on.
mikelutz Michael Lutz, working on some migrate and other issues, and keeping informed.
webchick Angie, Vancouver-ish BC, product manager, just keeping tabs, atm.
mirom Miro, Slovakia, just trying to followup discussion
catch Nat from the UK. Here for release/framework manager-y things.
tatarbj Balazs from Belgium, mainly to silently following.
gaborhojtsy [3:05 PM] one: Our master issue is at #3007300: [META] Release Drupal 9 on June 3 2020. Our other issues are children of this one and form this nice tree: https://www.drupal.org/files/issues/2018-10-26/%5BMETA%5D%20Release%20Dr... We identified a lot of things since the last meeting and will delve into specifics in further agenda items. Any major blockers that we forgot?
gaborhojtsy [Oct 29th at 3:07 PM]
:two: Migrate! The team has been working hard to close more multilingual blockers. The outstanding question on supporting Drupal 6 to 9 migrations seems to be resolved with building it in Drupal 8 and deprecating it for removal in Drupal 9 (moving to contrib). The Drupal 8 to 8 (AKA 8 - 9 migration path) was also discussed on the core committer meeting two weeks ago. Alex Bronstein was to post an update on the issue about update.php vs. migrate considerations for Drupal 9 but I don’t think he did. Is this accurate? Other major outstanding migrate questions?

gaborhojtsy Relevant issues are #2208401: [META] Remaining multilingual migration paths
Drupal.org
[META] Stabilise Migrate Drupal Multilingual module
Problem/Motivation Migrate multilingual data from D6 and D7. Proposed resolution D6 migration and much of D7 is working so use those migrations, and their plugins as models for these migrations. It is preferred to improve the existing destination plugins instead of creating new ones. Remaining tasks Because D6 is nearing end of life, the D6 multilingual migrations are the highest priority as shown in the list below. Top Priority
Mar 1st, 2014 at 2:11 PM
gaborhojtsy and #2607524: [meta] Migrations from Drupal 8 to Drupal 8 and Drupal 8 to Drupal 9
Drupal.org
[meta] Migrations from Drupal 8 to Drupal 8 and Drupal 8 to Drupal 9
Problem/Motivation We will eventually need to migrate Drupal 8 to Drupal 9 (and possibly Drupal 10). Also while it's less common, there are use-cases for migrating Drupal 8 to Drupal 8 - things like migrating a multi-site to domain module. Proposed resolution Add Drupal 8 source plugins, and test coverage for an 8-8 migration. This will provide the basis for the 8-9 migration path, since these would only change to due to changes in the migrate API in 9.x
Nov 3rd, 2015 at 12:00 PM
heddn We've got more of the multilingual migrations identified now, mainly the ones that were lacking were for D7 => D8.
gaborhojtsy I think some D7 blockers are out of the way to work on more of them
mirom Will we need to do 6/7 to 8 and then 8 to 9 migration or given that 8 to 9 should be simple (?) we would be able to go straight to 9?
gaborhojtsy @mirom the 6->8 migration is now in Drupal 8, based on our prior discussions that means we also need to build the 6->9 migration path in 8 (to be released in 8.LAST)
mikelutz @mirom 7 to 9 would be supported in core, 6 to 9 would be supported in contrib, theoretically.
gaborhojtsy @mirom it would be deprecated and not released in 9 though, that is the current plan in my understanding
mikelutz The big outstanding question is, what is the difference between 6->8 and 6->9 if the stable apis are the same.
gaborhojtsy Nothing :slightly_smiling_face:
gaborhojtsy the reason of the removal in 9 was so that it does not need to be supported until 9.LAST
mikelutz Which goes back to the question of 8->9 migration vs update.
gaborhojtsy @mikelutz yeah MY recollection of the core committer meeting was that update.php should be feasible for 8.LAST to 9 (or 8.anything to 9 really) due to possibility to go from 8.anything to 8.LAST which is the same in terms of non-deprecated APIs as 9
gaborhojtsy but @effulgentsia was supposed to post more about that on the issue and that did not happen :disappointed:
gaborhojtsy @catch may be able to provide more info on that (if needed) :slightly_smiling_face:
catch Yes we’re already updating minors with update.php, theoretically 8-9 might have no database updates at all, compared to say 8.5-8.6
gaborhojtsy So a lack of 8-8, 8-9 migration path should not block Drupal 9's release / branching then.
catch Having said that, people may well want to do 8-9 migrations to do things like site rebuilds, switching from file/image to media and similar. So offering proper migration is good, but probably doesn’t need to block the 9.0.0 release.
gaborhojtsy we’ll need to go back and update #2607524: [meta] Migrations from Drupal 8 to Drupal 8 and Drupal 8 to Drupal 9 with that :slightly_smiling_face:
gaborhojtsy I did all the updates on issues following our last meeting, so can do this pasting in the info from @catch :slightly_smiling_face:
gaborhojtsy if nobody else gets around to it sooner :smile:
gaborhojtsy that leaves us with these requirements then:

[1] make migrate multilingual stable
[2] deprecate Drupal 6 migrations to be moved in Drupal 9 core to contrib

and this ideally but not required:

[3] 8-8 / 8-9 migration support

heddn ^ #2 above makes me very happy
heddn https://drupal.slack.com/archives/CDDD98AMN/p1540840763015600 is an interesting read
gaborhojtsy [Oct 29th at 3:19 PM] three: Contrib versions and core compatibility. We identified two possible paths forward. (a) Core compatibility takes multiple values, 8.x, 9.x let’s say but we keep the version numbering scheme. That only requires #2807145: [policy, no patch] Allow contrib projects to specify multiple major core branches. (b) The better solution is semantic versioning, to decouple core compatibility numbering from the contrib version numbers. @mixologic identified a bunch of issues at #3009338: [META] Support semantic versioning for extensions (modules, themes, etc) in Drupal core, and allow modules to be compatible with Drupal 8 and 9 at the same time
Drupal.org
[PP-1] Allow contrib projects to specify multiple major branches for the 'core' key in .info.yml
Problem/Motivation If Drupal 9 only (or even nearly-only) drops backwards compatibility with Drupal 8, then Drupal 8 modules using the latest 8.x APIs should work with 9.x However the core key in .info.yml only supports a single version (6.x/7.x/8.x) - anything else just gets rejected. Proposed resolution We already supported versioned module dependencies, so could potentially use some of that logic and/or composer's format. Remaining tasks
Sep 27th, 2016 at 6:43 AM
Drupal.org
[META] Prepare core and Drupal.org to handle semantic versioning for contrib extensions (modules, themes, etc)
Problem/Motivation At #1612910: [policy, no patch] Switch to Semantic Versioning for Drupal contrib extensions (modules, themes, etc) we finally decided to allow Drupal contrib extensions to use pure Semantic Versioning (SemVer). At over 400 comments, that issue is no longer useful to get anything done. ;) This issue is the meta plan for tracking progress implementing the fixes to allow both semver and legacy versions, both within Drupal core and on Drupal.org and related packaging/distribution infrastructure. Proposed resolution
Oct 25th at 5:08 PM
gaborhojtsy (a) is needed either way, at least if are to keep the info file compatibility bit
gaborhojtsy so if a admin_menu-8.x-3.2 is to become admin_menu-3.2 it should still be able to say which cores it is compatible with
gaborhojtsy and we need to keep the info file compatibility bit for 8.x compatibility sake, so that needs to be improved
mirom can we replace core compatibility in info files with composer constraints? (edited)
gaborhojtsy Drupal 9 could do that but for a module to be compatible with Drupal 8 and 9 info files would still need to be there
gaborhojtsy I guess it could be that Drupal 9 does not look at the info file and then we keep the info file format as-is but then we have a file with misleading compatibility info :wink:
gaborhojtsy so far I’ve seen @catch favor at least doing #2807145: [policy, no patch] Allow contrib projects to specify multiple major core branches
gaborhojtsy for D8 compatibility sake
mixologic Seems as though we could allow composer constraints in the core field, and treat `8.x` as meaning `^8` (edited)
catch Drupal 8 could deprecate .info.yml, but to do that it would have to fully support composer.json, which it does not.
mirom is there any chance to introduce that in 8 release cycle? doesn’t seem like bc break as d.o generate composer.json anyway
mixologic To do that, however would mean core would need to use Composer's semver library in all of the places that it currently does 'compatibility' checks.
catch There’s this issue, it has not had much activity in the past year or two: https://www.drupal.org/project/ideas/issues/1398772
Drupal.org
Replace .info.yml with composer.json for extensions
Problem/Motivation
Jan 9th, 2012 at 11:40 AM
mixologic I really think that issue is a bit farther down the road though.
catch Yes for me getting .info.yml working with multiple major versions is orthogonal to switching to composer.json
mixologic Because even if we do that, core, itself, will still need to update the way that it handles alerting the user if they are trying to install/run updates for/do anything with/ a non-compatible module.
mixologic right now its a simple string comparison. That would need to be replaced with semver requirements checking.
mixologic which would pave the way for an easy transistion to composer.json's instead of info.ymls
gaborhojtsy that would certainly be better than making up our own format for the version compatibility info :smile:
mixologic Too bad .json is a terrible, terrible format for metadata. I really, really wish composer had decided on .yml instead.
catch Also we can’t do a 1-1 replacement of .info.yml and composer.json, stuff like theme regions does not belong in composer.json
mirom we can introduce package.json like symfony4 :smile:
gaborhojtsy [Oct 29th at 3:30 PM]
:four: 3rd party dependencies. We compiled meta issue at #3009213: [META] Update / reconsider PHP dependencies for Drupal 9. Work should be done on these ahead of Drupal 9 to prepare Drupal 8 to work with updated versions of those dependencies or when that is not possible to explore what needs to change in Drupal 9. These should be done NOW and not after Drupal 9 is opened. Which dependencies do we want to cover?
Drupal.org
[META] Update dependencies to appropriate major versions in Drupal 9
Problem/Motivation Dependencies of Drupal such as Symfony, Twig, Guzzle, etc. may become unsupported in Drupal 8's lifetime or Drupal 9's expected lifetime. Proposed resolution Update dependencies them to their latest (or other appropriate) major versions as applicable. Open child issues for each update. #3009219: Update Symfony to 4.4 in Drupal 9.0 #2568181: [META] Update to Twig 2.x in Drupal 9 #2631202: Doctrine no longer supports SimpleAnnotationReader, incorporate a solution into core #2917331: Decouple from Symfony CMF #2950132: Support PHPUnit 7 optionally in Drupal 8, while keeping support for ^6.5 Remaining tasks
Oct 25th at 8:59 AM

gaborhojtsy Propose a topic here, I’ll open a new point thread for stuff you want to discuss :slightly_smiling_face:
gaborhojtsy [Oct 29th at 3:31 PM]
:four:.:one: Doctrine. @catch proposed we discuss the simple annotation parser being deprecated that we need to build our own solution for. #2631202: Doctrine no longer supports SimpleAnnotationReader, incorporate a solution into core
Drupal.org
Doctrine no longer supports SimpleAnnotationReader, incorporate a solution into core
Follow-up to #2421451: Drupal needs comments in opcache Problem/Motivation SimpleAnnotationReader loads classes while parsing them. This puts more things in the opcache than we would like. Doctrine has essentially "won't fixed" this bug, since they're planning to deprecate SimpleAnnotationReader. References: https://github.com/doctrine/common/issues/607 https://github.com/doctrine/annotations/issues/87 https://github.com/doctrine/annotations/pull/199
Dec 8th, 2015 at 1:04 PM
(edited)
gaborhojtsy the current patch still depends on doctrine and just forks the classes that are being removed, is that what we should do?
gaborhojtsy ie. maintain a fork of the removed features for our own needs?

catch

Ideally we’d test that patch against Doctrine master to see if it’s enough.
heddn ideally we'd also account for https://github.com/doctrine/common/issues/744
GitHub
StaticReflectionParser is dumb, assumes Class::class references are class level · Issue #744 · doctrine/common
If I use the below PHP class structure, then parsing the annotations will always return an empty class level annotation. The current HEAD of https://www.drupal.org/project/migrate_source_csv is bro...
catch Although it might run into unrelated changes. I think compatibility with Doctrine master is what will end up being the minimum (i.e. as soon as they release), and anything else we might want to do is not really a requirement for Drupal 9. Ideally we don’t expose any Doctrine APIs at all so we could do further decoupling work during 9.x
catch @heddn is there an issue to update to 2.6? I couldn’t find one.
catch And am I right that bug is only fixed in >=2.6?
heddn @catch I assumed there was one and we were just waiting. The version sounds right. We should update.
catch @heddn I made the mistake of looking at composer.json - we’re using 2.6.2 in 8.7.x at least.
catch @heddn however were blocked on 2.8 until we drop PHP 7.0 support
heddn @catch we'd need only 2.7.3, but we can wait for php 7.0 and go the full way
heddn https://github.com/doctrine/common/releases/tag/v2.7.3
GitHub
doctrine/common
Doctrine Common. Contribute to doctrine/common development by creating an account on GitHub.
gaborhojtsy [Oct 29th at 3:36 PM]
:four:.:two: Symfony. There is a bunch of good work being done in #2937984: [META] Symfony 4.0 compatibility and it seems possible to make Drupal 8 run on symfony 4 (for those who want it). Symfony 5 will be released in a year, so we’ll need to do the same for that and see if we can use Symfony 5 in Drupal 9.
Drupal.org
[META] Symfony 4.0 compatibility
Problem/Motivation The Symfony 3.4 LTS will be EOL in 2021: http://symfony.com/doc/current/contributing/community/releases.html#sche... This means we need to be ready to move to Symfony 4 before then. Proposed resolution We should at least do the following: 1. Identify all the deprecated Symfony code that Drupal 8 relies on and update for it, opening issues for anything not straightforward #2959269: [meta] Core should not trigger deprecated code except in tests and during updates
Jan 19th at 6:01 AM
gaborhojtsy Once again the key here is the work (on Symfony 4 support) is possible and should be done now, no reason to wait for anything :slightly_smiling_face:
mirom when is symfony5 dev branch going to be opened? if we upgrade to the latest symfony4, then we should be able to upgrade to symfony5 without bc breaks won’t we?
heddn https://twitter.com/weaverryan/status/1055653217252638721
Ryan Weaver @weaverryan
@lucashedding Hey! Yep! See https://symfony.com/roadmap. Symfony releases come ever 6 months, and the .4 minor is the last one, always. Super, boring, consistent, awesome :). 5.0 will be released at the end of Nov 2019
TwitterOct 25th at 10:51 PM
catch The big change is that Symfony removed their autoloaders in 4.x and we use their apcu one, so we need to replace that. My persoinal preference is #2704571: Add an APCu classloader with a single entry but that was intended as an alternative rather than for this specifically.
Drupal.org
Add an APCu classloader with a single entry
Problem/Motivation Have been meaning to open this issue for years now. Latest reminder was bojanz linking to https://github.com/composer/composer/pull/5174#issuecomment-208824818 The apcu classloader from Symfony uses an entry-per-class. This means lots of sets and gets on each request. Also APCu doesn't handle LRU, or getting full very well, so it's prone to fragmentation. Proposed resolution
Apr 12th, 2016 at 6:51 AM
gaborhojtsy Symfony 5 is released stable in November 2019 and Drupal 9 is released sometime in 2020, so depending on the time diff between them Drupal 9 should be capable to depend on Symfony 5
catch We’ll need to keep up with deprecations in the 4.x branch to be able to use Symfony 5, but it’s feasible.
heddn @gaborhojtsy @catch see the tweet response from ryan weaver above
mirom @heddn does that mean that symfony5 development will start only in march 2019?
heddn @mirom https://symfony.com/doc/current/contributing/community/releases.html
Symfony
The Release Process (Symfony Docs)
The Release Process: This document explains the process followed by the Symfony project to develop, release and maintain its different versions. Symfony releases follow the semantic versioning strateg... (11 kB)
gaborhojtsy “The full development period for any major or minor version lasts six months”
mirom Thanks, I overlooked that
gaborhojtsy > Development: Four months to add new features and to enhance existing ones;
> Stabilization: Two months to fix bugs, prepare the release, and wait for the whole Symfony ecosystem (third-party libraries, bundles, and projects using Symfony) to catch up.
gaborhojtsy so by september 2019 the Symfony 5 API should be clearly defined I guess
catch The challenge is whether there are API changes between Symfony 3 and 5 that modules written for Drupal 8.x and 9.x are unable to bridge. So far there is nothing like that in Symfony 4 though.
gaborhojtsy Fingers crossed :slightly_smiling_face: We have #3009219: Update Symfony to 4.4 in Drupal 9.0 targeted at 4 or 5 to be safe :smile:
Drupal.org
Update Symfony to 4 or 5 in Drupal 9
Problem/Motivation The Symfony 3 will be end of life in 2021. This means we need to be ready to move to Symfony 4 or 5 before then. This is a major trigger to releasing Drupal 9 in 2020. See #3007300: [META] Release Drupal 9 on June 3 2020. Proposed resolution Update to Symfony 4 or 5. Remaining tasks First need to be compatible with Symfony 4. See #2937984: [META] Symfony 4.0 compatibility which aims to implement Symfony 4 compatibility in Drupal 8 itself.
Oct 25th at 9:03 AM
catch Even if there are, we can try to bridge them ourselves by providing bc in Drupal 9, just have to wait until this time next year to find out :stuck_out_tongue:
gaborhojtsy [Oct 29th at 3:46 PM]
:five: Experimental modules (other than migrate). We have a meta issue at #3007166: [META] Stabilise and/or remove experimental modules as appropriate in/before Drupal 9. The current plan is 8.LAST will not include any beta level code, so experimental modules either need to get stable by then or get removed from 8 (and kept in 9).
Drupal.org
[META] Policies and plans for stabilising and/or removing experimental modules in preparation for Drupal 9
Problem/Motivation A pre-requisite of releasing Drupal 9 is that we don't keep experimental modules around. We either need to stabilise them or remove them. Proposed resolution Field Layout: #3007167: [policy] Deprecate field_layout module and move it to contrib Layout Builder: #3009533: [META] Stabilize Layout Builder module in Drupal 8.7.0 Media Library: #2834729: [META] Roadmap to stabilize Media Library Migrate Multilingual: #2208401: [META] Remaining multilingual migration paths Workspaces: #2732071: WI: Workspace module roadmap New items needed as soon as new experimental modules are added.
Oct 16th at 4:29 PM

gaborhojtsy We identified the issue list for all current experimental modules for them to go stable, except Workflows.
gaborhojtsy @amateescu said he will collect those issues and open an issue tomorrow :slightly_smiling_face:
gaborhojtsy I will make sure to link that in the meta
gaborhojtsy last meeting @webchick also identified a bunch of potential experimental modules to be added, but they would need to stop being added by 8.8 or so to have a chance to even get stable before 9
gaborhojtsy nonetheless, due to the continuous upgrade path and extended security coverage in core, people relying on those experimental modules for some reason will have some time to hop over to Drupal 9
mirom will the code be moved into contrib or you don’t think that those modules will be added back to d9 later in d9 cycle?
gaborhojtsy experimental modules would be kept in Drupal 9 if they are planned to be staying in core :slightly_smiling_face:
gaborhojtsy they would not be released in Drupal 8.LAST though
mirom so if you depend on any of them, you would go from 8.LAST-1 to 9?
catch That’s right. Because we now support minor versions for one year, this means you get 6 months security support in which to do that.
gaborhojtsy [Oct 29th at 3:54 PM]
:six: Our own deprecated things and its testing for contrib modules. We have a META to track those, #3007329: [META] Drupal 8 core must not use any deprecated code, must be enforced by automated testing and #3002148: Support deprecation testing for multiple branches on contributed modules on Drupal.org
Drupal.org
[META] Drupal 8 core must not use any deprecated code, must be enforced by automated testing
Problem/Motivation In preparation of Drupal 9, depreciated code should be isolated and possible to be removed without affecting the rest of core. Proposed resolution #2093143: [meta] Remove calls to @deprecated and "backwards compatibility" procedural functions from core #2959269: [meta] Core should not trigger deprecated code except in tests and during updates #2856742: [meta] Adopt trigger_error() for deprecation messages where it is missing #2735005: Convert all Simpletest web tests to BrowserTestBase (or UnitTestBase/KernelTestBase)
Oct 17th at 9:57 AM
Drupal.org
Support deprecation testing for contributed modules on Drupal.org
Problem/Motivation Drupal core benefits from proper deprecation testing use @trigger_error(... - see https://www.drupal.org/core/deprecation.
Sep 25th at 5:09 AM

gaborhojtsy A big shout-out to folks working on eliminating simpletest here, we are down to 32 tests on simpletest and thousands on phpunit!

gaborhojtsy

See http://simpletest-countdown.org/
gaborhojtsy but that is only one of the many things that can be worked on now :slightly_smiling_face:
lendude @gaborhojtsy :+1:, as an update on that, the remaining 32 are mostly pretty weird edge case type stuff, so if people are looking for a nice challenge, go for it :slightly_smiling_face: but outside that, any feedback and reviews on the remaining items is greatly appreciated
gaborhojtsy [3:57 PM]
:seven: Open floor! Any topic you missed? Wanted to discuss but was not raised?

gaborhojtsy [Oct 29th at 4:00 PM]
:eight: Thanks all for coming! Our next meeting will be in 2 weeks. Propose agenda items for that at #3010097: Drupal 9 readiness meeting agenda / 12 November 2018, see you online in the meantime :slightly_smiling_face:
Drupal.org
Drupal 9 readiness meeting agenda / 12 November 2018
Hello and welcome to this Drupal 9 readiness meeting! This meeting: ➤ Usually happens every other Monday at 20:00 CEST / 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: `#3007152: Drupal 9 readiness meeting agenda / 29 October 2018`
Oct 29th at 3:59 PM

gaborhojtsy I hope to get slack admins help me post the meetings notes for this meeting at #3007152: Drupal 9 readiness meeting agenda / 29 October 2018 :slightly_smiling_face: thanks @justafish for posting last meeting’s notes at #3007136: Drupal 9 readiness meeting / 15 October 2018 :slightly_smiling_face:
Drupal.org
Drupal 9 readiness meeting agenda / 29 October 2018
Hello and welcome to this Drupal 9 readiness meeting! This meeting: ➤ Usually happens every other Monday at 20:00 CEST / 15:00 ET (for this week). ➤ 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: `#3007152: Drupal 9 readiness meeting agenda / 29 October 2018`
Oct 16th at 2:56 PM
Drupal.org
Drupal 9 readiness meeting / 15 October 2018
Moderated By: gaborhojtsy [0] Let’s introduce who we have here and what are you all here for gaborhojtsyGábor trying to get his stuff together :smile: looking forward to map out the tasks and timelines xjmHi! xjm, D8 release manager. So basically I have to care about everything we need to do with D8 and D9 core to get to that 2020 release date for 9.0.0. :slightly_smiling_face:
Oct 16th at 2:02 PM
gaborhojtsy Feel free to continue discussions above in the meantime, will take the meeting log in a few days :slightly_smiling_face:

Gábor Hojtsy credited Lendude.

Gábor Hojtsy credited Mixologic.

Gábor Hojtsy credited NickWilde.

Gábor Hojtsy credited heddn.

Gábor Hojtsy credited mirom.

Gábor Hojtsy credited tatarbj.

Gábor Hojtsy credited webchick.

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented
gábor hojtsy’s picture

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

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.