At the very top of the evaluation diagram at https://www.drupal.org/contribute/core/beta-changes (which was used during Drupal 8's beta), there's a bubble which indicates that feature requests should automatically be postponed to the next major version of Drupal core.

I think this should be reconsidered for the future, at least for features that can be backported to the previous stable release (e.g. from Drupal 9 to Drupal 8) but maybe for all features.

New features (especially those that are backportable) aren't necessarily risky at all. There are still other evaluation criteria in the diagram (e.g. the "impact vs disruption" comparison) that would block certain features from getting in if they are too risky, but I don't think we should necessarily block all features.

Blocking them all would essentially mean Drupal 8 can't get any newly-proposed features during that time period either (see #2350615-70: [policy, no patch] What changes can be accepted during the Drupal 8 beta phase? and subsequent comments), which could be an issue depending on exactly where Drupal 8 is in its release cycle at that point. If Drupal 9 doesn't have a eternally-long beta period, the concern is lessened, though :)

Comments

David_Rothstein created an issue. See original summary.

effulgentsia’s picture

effulgentsia commented

The diagram in the issue summary of #2135189: Proposal to manage the Drupal core release cycle shows that 8.x would be in LTS mode shortly after the 9.x branch is opened, and we could probably even choose to delay a 9.x beta on that happening. So the set of backportable features at that point could be quite small, maybe even 0, depending on how we define "feature".

David_Rothstein’s picture

David_Rothstein commented

My thought is that we're unlikely to want to actually put 8.x in LTS mode at that point (since it would potentially mean a years-long gap where no features are added to the version of Drupal core that many sites are actually using - and that's exactly what everyone wants to avoid).

But it's possible things will be different, e.g. if Drupal 9 has a shorter release cycle or is an easier upgrade from Drupal 8.

catch’s picture

catch
he/him
Primary language English
commented

I think we should be aiming for as short as 6 months between opening 9.x and releasing 9.0.0, with the 8.x LTS coming out on the same day as 9.0.0.

This might mean we finalize experimental features in 8.x and 9.0.0 but don't add new big ones until 9.1.

effulgentsia’s picture

effulgentsia commented

with the 8.x LTS coming out on the same day as 9.0.0

Some data points about this. When we were discussing this 2 years ago in #2135189: Proposal to manage the Drupal core release cycle, we were thinking that an 8 LTS coming out 6-9 months before 9.0 would be acceptable, because it would mean that just as you could get new features every 6 months via 8.0 to 8.1 to 8.2, etc., you could keep that going via 8.LAST to 9.0. There are other projects that follow this model, including Joomla (3.0 was released 8 months after 2.5), and at the time, Symfony, which was planning on the same in terms of 3.0 coming out 6 months after 2.7.

However, since then, Symfony decided on releasing a 2.8 LTS on the same day as 3.0. So catch's suggestion of doing similar for an 8 LTS on the same day as 9.0 is definitely worth considering. However, unless we're willing to have multiple LTS's within a single major, as Symfony does, this would delay 8's LTS relative to our earlier thinking, which might have down sides to some/many site owners.

catch’s picture

catch
he/him
Primary language English
commented

Posted #2608062: [META] Requirements for tagging Drupal 9.0.0-alpha1 to talk more about how to open 9.x, which in turn affects what we do here.

catch’s picture

catch
he/him
Primary language English
commented
Version: 9.x-dev » 8.1.x-dev

Also this is a decision we ought to make before 9.x opens, so moving back to 8.1.x.

xjm’s picture

xjm
she/her
Primary language English
commented
Parent issue: » #2615502: [meta] Plan the core development and release process for 8.0.1 and beyond
xjm’s picture

xjm
she/her
Primary language English
commented

Note that I'm not sure the exact D8 beta policy will reappear for D9. We devised it to resolve a specific need with a release that had far too much change in its scope and unmanageable technical debt. I think we learned a lot from the restrictions we set, and they served their purpose in terms of helping us get to release on time, but I'm hoping that the changes we've made will ensure we never need a year-long beta again, and therefore this will never matter again.

xjm’s picture

xjm
she/her
Primary language English
commented

Also see my comments on #2455081: [policy, no patch] 8.1.x release schedule. In that issue, I propose that instead of there being dead stretches with no feature development, we open the next feature branch for fixes as soon as a beta is tagged, unless the technical debt has become unmanageable.

So I'd propose closing this issue as works as designed or duplicate, and then discuss the special case of Drupal 7 separately in #2598382: [policy] Adopt a 6-month feature release schedule for Drupal 7 (similar to Drupal 8) and use pseudo-semantic versioning and #2598662: Decide when Drupal 7 (and Drupal 8 and later) should enter the LTS and security-support-only phase.

catch’s picture

catch
he/him
Primary language English
commented
Status: Active » Closed (duplicate)

Yes I think we should learn from Drupal 8 (and 7) and never get into that situation again, so agreed with #10. Going to mark this as duplicae now.