Drupal 11.2 compatibility planning

Thanks for raising this @catch! I agree things could have gone smoother; the 1.0 timing was really weird.

1.1, to be fair, will release about a month after 1.0, and its main change will be the inclusion of a read-only XB demo.

Then 1.2 will probably (I'm guessing) be three months after that, which brings us to..May? But that's when core 11.2 would enter beta, right? We don't want to release a new minor that depends on a core beta.

So I propose that we enter 1.2 beta in May, at the same time as core, and release 1.2 stable in June, at the same time that core releases 11.2. That gives people something reasonably stable to test with, and time to find bugs that need fixing before core's RC.

That'd be a month later than we'd ideally like, but it would compensate for the weird shift with our 1.1 release timing to accommodate the (talented, handsome, hard-working!) XB team.

At that point, we'd enter a more regular release cadence. 1.3 would come out three months after that, and depend on 11.2; three months later, 1.4 would come out and depend on 11.3, and so forth.

I am not sure Drupal CMS has much reason to tag alphas at all, to be honest. Since we have no APIs and no update paths, what does releasing an alpha gain us? If we make beta releases that depend on core betas, at least we can depend on a stable core update path.

So I propose that we enter 1.2 beta in May, at the same time as core's 11.2 beta, and release 1.2 stable in June, at the same time that core releases 11.2. That gives people something reasonably stable to test with, and time to find bugs that need fixing before core's RC.

So I think this is great for testing and bugfixing, but it would not help with 11.2 issues that haven't landed yet that will affect Drupal CMS.

For a concrete example let's say the linkit issue lands in core one day before core beta1 is tagged (or during beta). This doesn't give any time to incorporate it into CMS beta1.

Soes that allow a window to still include it in Drupal CMS during the beta? Or would it need to wait for the next CMS release after that?

Obviously the best way to avoid this would to have all the relevant issues committed weeks in advance but even if we have a list of issues now and get them all done, there will be new ones that show up.

To continue with that example...my inclination is to say that, if the LinkIt issue landed in core a day before beta, then we would incorporate it into Drupal CMS during beta, if it were a reasonably easy lift. If it was harder to do, then we'd probably keep using the contrib LinkIt module and target adoption of the core LinkIt functionality for our next minor.

Just to be clear, I have not discussed any of this with Tim or Pam; it's just the approach I would probably take if I was king of this project.

#4 seems reasonable. We don't actually freeze new features during core betas, it's more that we might not backport something from the next minor branch if it's likely to be disruptive - however a lot can still get in. We do freeze new features during the rcs though unless it gets an explicit exception - same commit rules as patch releases during rc. I think this is where the windows didn't really line up for 11.1/1.0, because we were still committing features to core when Drupal CMS' feature freeze was starting.

If I understand the schedule, does this mean that you're talking about quarterly minor releases, with two scheduled for the week as Drupal core minor releases, and two equidistant in-between? (at least from the middle of this year if not straight away).

I think so.

@catch, do you by any chance have the exact dates that Drupal core will go into its betas for 11.2 and 11.3, and when the minor releases will drop? Because then I could draw up a plan here with proposed exact dates for Drupal CMS releases, and that would make it a lot easier to keep track of what we'd like to happen, when.

The release windows are an entire week, but yes they're listed here for 11.2 https://www.drupal.org/about/core/policies/core-release-cycles/schedule → - can't assume that the beta will start until the end of the window. 11.3 is TBD (but probably 11.3.0 in second week of December, don't quote me).

If Drupal CMS can manage shorter beta/rc periods, then it could set its own beta/rc windows to start on the Monday after core's one week windows. And then the final release date 'the same week'. And that ought to be a reliable schedule then as long as we don't tag 11.2.0 last thing on Friday night (which is what happened with 11.1, but partly due to a lot of scrambling in the week before).

OK, so here's what I would propose (all dates in 2025).

Given that Drupal core does this:

11.2.0-beta1: May 19-23
11.2.0: June 16-20

Then Drupal CMS does this:

1.1.0-beta1: February 5
1.1.0: February 19
1.2.0-beta1: May 28
1.2.0: June 25

11.2.0: June 16-20
..
1.2.0: June 25

If there are compatibility issues with 1.1.x and 11.2.0 for any reason, then this leaves up to 9 days of broken installs where people are installing Drupal CMS 1.1 with core 11.2.0.

For that reason I think it would make sense to start the release window on the same day as the beginning of 11.2.0's release window, but maybe extend it longer until June 25th (in case there aren't compatibility problems with 1.1 to sort out, but there are things to iron out in 1.2 still)? At least for the first time to allow for some flexibility. So it would look like 1.2.0: June 16-25 then.

Connecting this to the top level planning for 11.2/10.5. And tried to convert the dates to a table and added to the issue summary.

Previously it was said that the CMS release with XB would be 2.0 but I see that’s changed here. We should make sure that’s made clear to the leads and advisory council so we’re all on the same page. I’ll link this in slack.

It hasn't changed, we're just using 1.x versions for planning purposes because we can't be certain when XB will be ready.