Meeting will happen in #d10readiness on drupal.slack.com.
Gábor Hojtsy (he/him) |
Thanks folks for the fantastic work on this. I don't know if I could name all the names but least @Spokje, @Björn Brala (bbrala), @larowlan, @quietone, @catch, @dww and others have been instrumental here. |
Spokje |
So hal has left the Core building, a lot of people put a lot of effort into making a solid base (and more!) to getting the whole process formalized (https://i.imgflip.com/669nbn.jpg).Besides aggregator being the top-priority, is there:A preferred order for the other nominated modules?A possibility to deprecate core modules that didn't make the deprecation-cut for D9.4.0 in minor versions of D10 for deprecation in D11? (I don't see all nominated modules making it and want to prevent us from starting too late Yet again as we seemingly did in 8.9 and probably will in 9.3)(edited) |
Gábor Hojtsy (he/him) |
#3266219: [policy, no patch] Document the approach and issue scope for removing modules from core is the policy as pointed out by @Björn Brala (bbrala) (for the recording and those who are not aware yet) |
Gábor Hojtsy (he/him) |
@Spokje I don't think there is an order other than aggregator being the top priority due to the risky depenendcy and YES we should continue to evaluate and deprecate modules in Drupal 10 going forward. |
catch |
I don't think there's a preferred order either but we might want to come up with an informal one to make things easier on ourselves. |
catch |
Well maybe 1. Aggregator 2. Quickedit since quickedit removes some JavaScript surface. After that afaik no order yet. |
Spokje |
I would propose after that Core modules that already have a release out in Contrib? Like for example https://www.drupal.org/project/forum |
catch |
Yeah anything with some work done means less to remove. |
dww |
QE is actually pretty close. The main removal issue is down to blocked on 2, and one of those is nearly RTBC. |
mstrelan |
Added a very rough draft MR to the second QE blocker. Needs work. |
quietone |
Update the deprecation meta based on this discussion. |
quietone |
Also, trialing the steps in the module deprecation policy with the tracker migration. I'll do that same for aggregator, quickedit and forum if anyone thinks it would help (and not interfere with what is already happening). |
Spokje |
quickedit might be a special snowflake, since it was our first stab at deprecation/removal, so we kinda whacked a whole lot in one issue.I think for that one it might help (certainly won't hurt), for the others I can see only good things coming out of it.(Reducing of MR size, no unexpected blockers, etc.).So for me it's a big YES! (FWIW) |
quietone |
OK, I will embark on some issue admin. |
quietone |
aggregator, quickedit and forum now have a Meta to track the entire process. I am sure it still needs adjustments as we find our way. The meta for each module can be found on #3118154: [meta] Deprecate dependencies, libraries, modules, and themes that will be removed from Drupal 10 core by 9.4.0-beta1#comment-14428998 |
dww |
Fabulous, thanks! |
quietone |
Your welcome. And RDF has been added to the can be worked on list because the policy issue is RTBC. |
Spokje |
Awesome work = awesome! |
Gábor Hojtsy (he/him) |
This would involve the child issues of #2659890: [Policy] [Plan] Drupal 9 and 10 markup and CSS backwards compatibility |
Gábor Hojtsy (he/him) |
@danflanagan8 was proposing this topic with a specific interest to get reviews on #3083275: [meta] Update tests that rely on Classy to not rely on it anymore |
Gábor Hojtsy (he/him) |
I think at least @mglaman was really keen to contribute in this area. |
Gábor Hojtsy (he/him) |
But there are likely more :) |
danflanagan8 |
It's the kind of unglamorous work I am drawn to for some reason. :slightly_smiling_face: |
danflanagan8 |
It looks like maybe I'd be better off working on 3️⃣.6️⃣ , which is similar but more important |
Gábor Hojtsy (he/him) |
@danflanagan8 yeah that is also useful, that would help us remove Bartik :slightly_smiling_face: which I guess is probably also a pre-requisite anyway to remove Classy, since it depends on Classy |
Gábor Hojtsy (he/him) |
(unless we flatten Classy into it if other core dependencies get removed, which sounds very unattractive :smile: ) |
xjm |
@danflanagan8 I actually think this is more important than Olivero |
xjm |
And less glamorous as you mention :slightly_smiling_face: So definitely an area where help is welcome |
mglaman |
I plan on working on the startkit hard soon. Because of my book, and in general it’s a huge experience win. I need to track the other parts which aren’t about the theme generation itself (started on more of that) |
danflanagan8 |
Nice. Maybe I can try to get things moving on the Classy tests then. |
mglaman |
ah yeah, this #3206217: Allow starterkit themes to control how the theme is generated |
mglaman |
Is there any kind of basic scrum for this initiative? I know @lauriii and @mherchel and I had a few talks, that’s about it |
mglaman |
(I know we all don’t need more meetings… but maybe just the #d10readiness meetings on monday suffices? |
lauriii |
I think this is a good place to catch up on |
lauriii |
I already pinged @alexpott about that issue since I’ve discussed it with him earlier |
mglaman |
I saw he :eyes:’d it |
Gábor Hojtsy (he/him) |
@mglaman we already have the Drupal 10 meeting weekly and can raise this as a standing item :) |
Gábor Hojtsy (he/him) |
@daffie raised this #3266764: [11.x] [policy] Treat SQLite as a dev (rather than prod) requirement and allow it to be raised in Drupal minors |
daffie |
@catch Can we talk about this? |
catch |
Yes but probably tomorrow? |
andypost |
Let's wait a week or two if there will be .1 release |
daffie |
Tomorrow is fine and lets wait for the .1 release. |
xjm |
Ooh, we need to be careful about these issues. We told people the SQLite minumum requirement was already finalized. |
catch |
Sorry I meant to come back to this then... didn't. Put a couple of thoughts on the issue, just thoughts nothing concrete really #3266764: [11.x] [policy] Treat SQLite as a dev (rather than prod) requirement and allow it to be raised in Drupal minors#comment-14432534 |
xjm |
The person I know who surfaced issues the last time we raised the requirement aggressively (for D9) was Sam Mortenson, but he's mostly not doing Drupal development anymore and I don't know what his usecase was |
xjm |
It also seems awfully short notice to demote it to be dev-only (edited) |
daffie |
The problem is that the added functionality in SQLite 3.38 makes it a lot easier to search JSON field storage data. That is why I am asking for it. See: #3046696: Move from serialized columns to JSON encoded data wherever possible, or use allowed_classes (edited) |
xjm |
@daffie I understand why the issue is desirable, I just don't think we can get away with it for D10 |
xjm |
As I stated in my issue comment, the availability of useful features is not what drives our DB support policy and if we wanted to make this change of the "not supported for prod" SQLite driver I think it would need to be a D11 one |
daffie |
@xjm That is fine. Thank you for your time and wait with this one for D11. |
xjm |
We will probably open 11.0.x development in the end of 2023 so it's not all that long of a wait potentially :slightly_smiling_face: |
Gábor Hojtsy (he/him) |
Raised by @daffie, see #3266252: [policy] Release a Drupal 9.10 that uses Symfony 5.4 and CKEditor 5, and is supported until 2024 |
Gábor Hojtsy (he/him) |
I put “Drupal 9” into quotes in the topic as I don’t think it could semantically be Drupal 9 per say if it would be on Symfony 5.4, but that probably should not stop the discussion by itself :slightly_smiling_face: |
daffie |
I am just worried that after the release of D10 a number of contrib module will need a D10 release. Especially for the by Symfony 6 added return type hints. That will leave site owners ver little time to upgrade to D10. With this "D9" version they will have 2 extra years. |
Gábor Hojtsy (he/him) |
@catch or @xjm would be the respective core committers, but that should not stop others from discussing either :) |
catch |
With return type hints can't contrib just require PHP 8 and be OK? |
daffie |
Not if you are extending a Symfony class that has those added return type hints. (edited) |
catch |
But if you add a return type hints that won't break Symfony 4 compatibility though. |
daffie |
They are required in Symfony 6, not in Symfony 5. There you only get a deprecation warning. |
daffie |
AFAIK an extending class can add return type hints without a problem. We did that in a lot of core issues in preparation for the upgrade to Symfony 6. |
catch |
Yes but you can add a return type hint in a subclass before the parent class does. |
catch |
So modules can support Symfony 6 (at least for this) without breaking Drupal 9/Symfony 4 compatibility. |
daffie |
AFAIK yes, they can. |
tr |
Um.. with caveats. Some cases require either conditional code or new branches in order to work with both Symfony 4 and Symfony 6. #3252757: Update Drupal 10 to depend on Symfony 6.0#comment-14418128 |
bircher |
I think this comes down to "what is the API of Drupal" aka the age old discussion. Because Drupal 9 could require symfony "4|5" and still be semver. I guess the problem is that most contrib/custom don't specify their own requirements explicitly if they implicitly depend on a dependency of core.. But I think the messaging around this should change and we should encourage explicitly defining dependencies when one does depend on drupals dependencies directly. But min-max testing would have to become a thing and maybe there are some tools that can help find such dependencies. |
longwave |
Agree with what @bircher said - but how to get this message across to contrib? And even if we can I am not sure this is achievable this late in the D9 cycle - maybe we can introduce it for D10 but then that doesn't help the problem at hand |
longwave |
"Drupal 9 with Symfony 5" might help contrib, but for end user sites is it worth it, or would we be discouraging users if they have to upgrade to Symfony 5 and then 6 in quick succession? Would it be better to work on automated tools to help with upgrading from D9/SF4 straight to D10? |
Gábor Hojtsy (he/him) |
I think working on automated tools would be better. I updated deprecation status (tool that processes all contrib's upgrade status results) to tell apart third party deprecated API uses detected and symfony was/is not very widely affected. |
Gábor Hojtsy (he/him) |
https://twitter.com/gaborhojtsy/status/1473014759947706369?t=62qnGc4LhHB... |
Gábor Hojtsy (he/him) |
There is a possibility that we are not finding some of them but that it would be a lot more I don't think? |
bircher |
@longwave yes I agree, it is too late for Drupal 9. I meant it is something of a cultural shift we could envision for Drupal 10 or 11. But it comes down to technically Druapl 9 the framework being compatible with Symfony 5 but Drupal 9 the product has as an "API" Symfony 4. I don't know if that is really a problem given that deprecations for symfony in contrib is very low |
catch |
Also no-one has pointed out an actual blocking issue with Symfony 4 to 6 in contrib yet - you can add type hints in Drupal 9, for some type hints you might need to raise your PHP version requirement, but that's still compatible with Drupal 9. If you don't want to raise your PHP minimum requirement, you can conditionally define classes or methods if you really need to. We've added forward compatibility layers for any breaking changes we found in core like the Event class and could add more if they come up. (edited) |
daffie |
If D9.4 will be the last regular D9 release, then my idea was to do a D9.5 release with Symfony 5.4. |
catch |
Right but I still don't understand the use-case or how we'd go about doing it:For contrib, there's no example of an issue forcing a 10.x branch yet that I know of.For sites, we don't want to update them to Symfony 5.4 unnecessarily.We don't have #3020303: Consider using Symfony flex to allow switching between major Symfony versions or min/max testing in place to allow a Symfony 5.4 update in a safe way. If we'd done this before 9.0.0 was released it'd be easier to do something like this now, but it didn't happen. |
daffie |
To me the use case is D9 sites that need more time to upgrade to D10 after D9 has gone EOL. Now with the D10 release date in august, they will have 15 months. That may should like a lot, but they this have to wait for all the contrib modules they are using to be D10 ready. That wait time will be removed from those 15 months. That time can become to short for some sites. A D9.5 with Symfony 5.4 will give them 2 extra years. That to me is the use case. |
catch |
But if contrib has to add Symfony 5.4 compatibility, they might not be able to immediately update to the 'minor' release either. |
daffie |
@catch: You are right about that. Did not think of that problem. |
bircher |
isn't that the same modules that also need to be adjusted for Drupal 10 then? I mean the modules that need to be adjusted to work with Symfony 5 also need to be adjusted for Symfony 6 not necessarily the other way around. So D9.5 with sf5.4 may give some sites more time but not necessarily all of them. I guess the question is what disruption it brings and if 9.4 to 10 is sufficiently easy to make a potentially risky 9.5 obsolete |
catch |
The issue with 8.9 to 9.x wasn't Symfony compatibility, but that there are thousands of unmaintained contrib modules. However things like the permissive packagist endpoint will make that less of a problem this time around. How much less of a problem is hard to tell. |
catch |
The other issue with a 9.5 is that Symfony isn't the only dependency going EOL, so is ckeditor 4 - we can't not ship ckeditor4 in a Drupal 9 version, even if we can (have to in 9.4) ship ckeditor5 as well (edited) |
bircher |
yea the thousands of unmaintained modules is a problem that will not go away no matter what strategy we have for release cycles or LTS versions (also hinting at that issue here because I think that is in a way a problem in the same space as this thread #3238652: [policy] Decide how long major Drupal versions should be supported) (edited) |
catch |
I think if we can get everyone to use >= 8.9 constraints instead of ^8 | ^9, then at least a lot of modules that are really low maintaince would not need it, at the cost of occasionally finding compatibility issues after upgrade instead of before. |
bircher |
I think that is a great idea and one I think we should communicate in various places blogs etc |
catch |
I thought I opened an issue, but maybe not, can't find it now. |
catch |
Opened a new one #3267143: Add a composer plugin that supports 'composer require-lenient' to support major version transitions |
xjm |
We posted an RM decision on #3266252: [policy] Release a Drupal 9.10 that uses Symfony 5.4 and CKEditor 5, and is supported until 2024#comment-14432779 to wontfix that particular proposal. (edited) |
bircher |
by the way I like and respect the decision not to release a 9.10 as described in the issue. But maybe another option is the following: |
bircher |
Release a version of Drupal 9 as it becomes EOL, ie an unsupporded release which relaxes the composer dependencies, "on your own risk" so to say.. or maybe not even a release but a "fork" which allows people to not move to drupal 10 but allows to keep it around.. |
bircher |
But also maybe it is worth saying EOL is EOL, upgrade your things in time.. |
Gábor Hojtsy (he/him) |
Some release of Drupal 9 will inevitably kick composer updates and update status to tell people to do it. And various people will do it without reading about it assuming it's yet another release and break their site. |
xjm |
I don't see why we should have all the disadvantages of having a release to support until 2024 without any of the advantages. |
xjm |
At Drupal 8's end-of-life, 56% of D8+ sites were still on D8. Three months later, now that we've released a couple required security updates, only 40% of D8+ sites are on D8 and the rest are on D9. That means a third of them upgraded already after three months.There are people who no matter what we do will not upgrade until they are forced, but from a release management perspective, this is actually going really well and I expect D10 will go even better. My primary concern is for larger sites that need a longer period to upgrade, and whether the 14.5 or 10.5 will be enough for them if they get blocked on contrib. |
xjm |
But I'm not concerned enough to force myself and everyone else to do hundreds of hours of extra work for very little gain. |
xjm |
Symfony deprecations are only 3% of contrib deprecated API uses. Our tools can help them. And they'll be fine. |
Comments
Comment #2
Gábor HojtsyExpanding topics a bit since we already know various things for this next meeting.
Comment #3
Gábor HojtsyComment #4
xjmComment #5
xjmComment #6
xjmFixing thread numbers, sorry.
Comment #20
Gábor HojtsySaving notes.
Comment #25
Gábor HojtsyComment #27
Gábor HojtsyAdding missing credit. Thanks all!