[meta] Release Drupal 10 on December 14... or 15... 2022

For 8.9.x we had a moratorium on new content upgrade paths, this has kept #3110367: [META] Beta blocking upgrade path bugs down to a finite (if still too long until this week) list. If we hadn't done that, we'd easily have added another 2-5 issues.

I think we should consider extending that upgrade path freeze a minor release earlier, so avoid committing any complex upgrade paths to either 9.x.LAST and 9.x.LAST-1. This gives us a longer period to resolve any upgrade path issues before 9.x goes EOL.

Stuff like incomplete deprecations, upgrade system API blockers, simpletest removal we won't have to deal with nearly as much next time because it will be the second release rather than the first on the new cycle, but upgrade path bugs we almost certainly will.

Overall we should be aiming to decouple our release schedule from Symfony's as much as we can - we were essentially forced to release 9.0 this year due to Symfony 3 EOL, when we didn't really have many other strong reasons for a new major version yet otherwise, the same is going to happen for Drupal 10.

For Symfony 5 vs. 6, we should revisit the ideas around using Symfony flex in #3020303: Consider using Symfony flex to allow switching between major Symfony versions - either to allow Drupal 9 sites to optionally update to Symfony 5, or to allow Drupal 10 sites to optionally update to Symfony 6 (or 7?). Also try to streamline our external dependencies, or improve our integrations so that upstream API changes don't affect us as much. #2917331: Decouple from Symfony CMF and #3054535: Discuss whether to decouple from Symfony Validator are two examples. This might give us more flexibility for when we release Drupal 11.

Increase and finalize the platform requirements for Drupal 10 earlier in the process. (We're running into both technical and community drawbacks from the fact that database requirements are down to the wire for the D9 beta.) Set a specific earlier deadline? Increase them to at least the obvious minima as soon as the branch opens, as we did for PHP? Etc.

Yes definitely. The problem with this though is that the earlier we try to increase requirements, the more pushback there is on doing so due to distribution support. Ideally we'd have a heuristic we can apply to stuff like this to make decisions quickly, but instead it is always a multi-month discussion. It was perhaps a bit better with PHP 7.3 this time.

Begin identifying requirements in child issues and start the most critical/disruptive requirements (like CKEditor 5

The scope of #3091226: [META] Select the best modern editor for Drupal 9 has been broadened to look at other modern editors apart from CKEditor 5, but that's even more of a reason to start early...

Oh, something else we should start sooner is deprecating dependencies, libraries, modules, and themes that should be removed in Drupal 10.

Yes #2152459: [Policy] Deprecate RDF module and move it to contrib first missed the 8.0.0 beta deadline, then missed the 8.8.0 beta deadline, it was opened in 2013.

Quite a big deprecation to sort out #3010983: Deprecate Drupal 6 and Drupal 7 migrations and move to contrib.

Re migrations there was a whole discussion of what migration paths should Drupal 10 support. Given the vendor extended support until at least end of 2024, should Drupal 10 core sill support a Drupal 7 migration path, or should that be "vendor extended" as well (ie. move to contrib)? In that case, what use case does migrate have in core, and should it be deprecated altogether and moved back to contrib in Drupal 10? Or should some other use case be found for migrate.

Ps. I don't think that is a discussion for this issue, but we need an issue :)

Opened #3118232: Should Drupal 10 support migrating from Drupal 7?.

Based on current policies, Drupal 10 can not be released on Symfony 6.

While Symfony 6 will be available by the time Drupal 10 comes around, it will only receive security fixes for 8 months (https://symfony.com/blog/symfony-maintenance-changes-for-standard-releases) so given that Drupal core is supported for 12 months, Drupal 10 cannot adopt Symfony 6.

Text borrowed from Gabor #3009219: Update Symfony to 4.4 in Drupal 9.0, just increased the version numbers.

Based on current Symfony and Drupal release policies, Drupal versions must follow the release schedule of Symfony LTS releases.

Symfony has agreed to accept Drupal contributors onto its security team, so that minor version security support can be extended to 12+ months. This means we have the option to jump to Symfony 6.0 and follow minor releases, if we're prepared to help with backporting security fixes for the components we use when needed.

Noting here that various people had concerns with introducing deprecations in a minor release that only goes end of life at the time of the new major release. Most recently Sam Mortenson at https://twitter.com/mortensonsam/status/1241469196711514112?s=20 (see whole thread).

Noting here that various people had concerns with introducing deprecations in a minor release that only goes end of life at the time of the new major release.

Maybe we could consider releasing 9.LAST.0 on the same day that 10.0.0-beta1 comes out (and ending the EOL of 9.LAST.x -2 on the same day too).

We've had to backport a lot of issues to 8.9.x and 8.8.x this time around, but a lot of that was technical debt from never having done this before, so there could feasibly be a lot less.

Making wishes here (wink).

IMO the code base of Drupal has become far too complicated for developer to read and use. Too many ways to do the same thing. Some in the function-centric manner like the old days. Some in complete OOP style. It would be great if Drupal 10 can focus on consolidate the parts into a set of more streamlined, predictable interfaces and thus improve the developer experience.

Also, WSOD is far to often to have occurred. The overall error catching / handling / reporting manner need some improvement for it to be as stable a platform as Drupal 7.

The Drupal 7 EOL date needs to be updated in the image in the issue summary.

This slightly edited Driesnote slide will be useful for reuse.

Are you planning to change EOL of D8 as you did for D7 to 2022 or it is a typo to show both of them ending in 2022 in the image describing EOL ?

@kiwad: the year numbers in the summary were the starts of the years not the end of the years (I know I've been confused by that before too). The figure is outdated, so I'm removing it from the summary and replacing for now with the Driesnote screenshot. Drupal 7 EOL was extended to Nov 28, 2022 (see https://www.drupal.org/psa-2020-06-24). However Drupal 8 EOL is still in November 2021 (yes, before Drupal 7's EOL) because Symfony 3 (that Drupal 8 depends on) will EOL in November 2021.

Would be great to resolve logo issue before releasing #2057767: [policy, no patch] Revise the Druplicon logo

Following discussion yesterday, here is the issue tree of Drupal 10 visualized. Also attached is the PHP script I used to generate it (almost entirely the same as I used in #3007300: [META] Release Drupal 9 on June 3 2020).

Updated the issue tree with various missing issues. Also fixing the midmap script.

I think we need to open/work on the Drupal 10 branch in roughly the following order. This is so that contrib can test against a target that is essentially Drupal 9 + Symfony 5.4

1. Open the branch (quite soon)

2. Set PHP 8 minimum compatibility (to PHP 8.0 for now, with the option to raise it later if we decide to)

3. Commit any outstanding child issues of #3161889: [META] Symfony 6 compatibility - some can only be committed against Drupal 10 due to relying on PHP 8.

4. Update to Symfony 5.4 and #3104353: Upgrade to Guzzle 7 + any other miscellaneous updates that can be done immediately.

5. Tag 10.0.0-alpha1 to have a testing target for contrib, with Symfony 5.4 (tag doesn't have to be alpha1 except that's probably the only thing that'll work with DrupalCI).

6. Start removing Drupal deprecated code and continue doing normal 10.x stuff as usual.

7. Possibly tag another alpha with Symfony 5.4 once Drupal deprecations are removed.

8. Update to Symfony 6 and tag another alpha.

9. Normal major release stuff otherwise in no particular order.

#33 this sounds reasonable, or potentially tagging alpha1 and alpha2 as more of these land (but making them blockers to removing Drupal deprecations).

Maybe instead of tagging early alphas core could make monthly alpha releases, so deprecations and new features would be easier for maintainers to follow adopt changes from 10.x, at least it will help to schedule transition time (sf5/sf6)

I am trying to make the game plan for phpstan-drupal for ensuring compatibility with Drupal 10 and Symfony 5.4 or 6 (https://github.com/mglaman/phpstan-drupal/issues/266)

Having monthly alphas would be great per #35. That way I could have a workflow which targets 10.x-dev and then one which only targets the alpha releases. That way I can ensure phpstan-drupal is working for folks as they begin preparing and scanning.

Alpha1 is now available at https://www.drupal.org/project/drupal/releases/10.0.0-alpha1

Further alpha releases will be made available, however our next set of requirments are for the beta release at #3118149: [meta] Requirements for tagging Drupal 10.0.0-beta1. The date of the beta will define when the final release date could be.

We did not yet define all the platform requirements yet (the PHP version remains in discussion, soon to be defined). So crossing some of the items in the issue summary "out of order".

Re this part in the issue summary I think that was decided against since we do allow for a lot of changes on 9.4.x actually, so crossing that out as well.

Decide whether to open 10.1.x to development earlier (potentially as early as 9.3.0-alpha1), since spending another six months in feature freeze so soon after 9.0 development might be unnecessary (given how close D10 will be to D9) as well as detrimental to innovation.

Updated issue summary for these, but the issue summary needs more updates.

https://www.drupal.org/project/drupal/releases/10.0.0-alpha2 is now also available. Updating the issue summary.

Cleaning up issue summary, updating title. This issue was not updated yet for December 14: https://www.drupal.org/about/core/blog/drupal-10-will-be-released-decemb...

Adding some key facts from the blog post.

Added the new 9.5 deprecation issue.

per conversation with xjm, added a could have section with a link to issues tagged beta target,

I just tried to run my module under 10.0.0-rc1 and received this error:
Declaration of Drupal\cf_hosted\RouteSubscriber::getSubscribedEvents() must be compatible with Drupal\Core\Routing\RouteSubscriberBase::getSubscribedEvents(): array
This agrees with the documentation here:
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Routing%2...
However the symfony interface it extends does NOT have the new :array output typehint
When I removed the typehint from core/lib/Drupal/Core/Routing/RouteSubscriberBase.php things seemed to work.

Please open a separate issue against Drupal core.