The goal of this issue is to discuss how and when we branch and release 8.1.x.

Proposed schedule

See the Drupal core release cycle overview for the most up-to-date proposal.

See also

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

xjm’s picture

Issue summary: View changes

Adding a link to the semver issue and its illustration.

From @catch in the summary of #2362647: [policy, no patch] 8.0.0 release candidates, release, patch versions:

  • 8.1.x won't be opened for at least two months, and not until there have been no outstanding critical issues against 8.0.x for a couple of weeks
  • 8.1.x beta will start four months after 8.0.0 is tagged, no new features allowed then and other patches may also be deferred to 8.2.x
  • 8.1.x release candidate will be tagged once there have been zero critical issues against that branch for 10+ days (critical issues against both 8.0.x and 8.1.x need more discussion)
  • 8.1.0 gets tagged once a release candidate has survived with no new critical issues for 10+ days

The first two points make sense to me. I don't agree with the last point because I think it's important to keep to the six-month release schedule. Instead, I think that anything that introduces critical regressions should be reverted until those regressions are resolved. If there are critical non-regressions (i.e. against both branches), then I think those trigger a feature freeze, similarly to how we used thresholds during Drupal 8 development. How exactly we'd apply the thresholds in the shorter cycle I'm less sure of.

xjm’s picture

Issue summary: View changes
catch’s picture

Per #2550249-7: [meta] Document @internal APIs both explicitly in phpdoc and implicitly in d.o documentation we need a string freeze so that translation coverage doesn't regress between minor releases - currently that issue says two months.

We'd likely need to let some minor string changes in during the last two months for typos or major/critical bug fixes, but that seems like the cut-off for hook_help() rewrites, brand new modules etc.

So as well as a strict 6 month schedule for release, we're also going to need a strict RC and beta schedule set ahead of time.

At a minimum I think we want 4 weeks for beta and 4 weeks for release candidate. That would give the 2 months/8-weeks string freeze then.

This means that big changes needs to be ready at the latest four months after the last minor release, or they'll get punted to the next minor after that.

webchick’s picture

Spending my Friday night going through "revisit before release candidate" issues...

I would propose that this doesn't need to get figured out before RC1. It does need to get figured out prior to 8.0.0. Can we remove the tag and explicitly add it to #2559575: [meta] The Drupal 8.0.0 Release Checklist instead?

catch’s picture

Yes to both.

webchick’s picture

Issue tags: -revisit before release candidate

Done.

xjm’s picture

xjm’s picture

So, revisiting this. It sounds like the proposal is:

  • 8.1.x won't be opened for at least two months, and not until there have been no outstanding critical issues against 8.0.x for a couple of weeks.
  • 8.1.x beta will start four months after 8.0.0 is tagged. No new features are allowed then and other patches may also be deferred to 8.2.x as well.
  • 8.1.x rc will start five months after 8.0.0 is tagged, and most patches are deferred to 8.2.x.

We've discussed whether opening 8.1.x earlier would be a good idea, because this leaves only a very short 2-month window for 8.1.x improvements to land. However, I do think it's very important to manage technical debt during 8.0.x; we are in a very bad situation in terms of the outstanding majors. So I'd propose that we still keep 8.1.x closed for awhile, but open 8.2.x as soon as 8.1.x goes into beta, so anything that lands during those two months can proceed safely. Suggesting some dates (taking into account that the first minor is actually only 5 months after 8.0.0):

November 19, 2015 8.0.0 released
January 6, 2016 8.1.x opens for development if technical debt is under control. (Criticals, possibly major bugs)
February 24, 2016 8.1.0-beta1 released. 8.2.x opens for development if technical debt is under control, and subsequent additions go into 8.2.x instead of 8.1.x.
March 16, 2016 8.1.0-rc1 released. Similar requirements to 8.0.0-rc phase for patches to go into 8.1.x after this point.
April 20, 2016 8.1.0 released
August 17, 2016 8.2.0-beta1 released. 8.3.x opens for development if technical debt is under control.
September 21, 2016 8.2.0-rc1 released. RC rules apply.
October 12, 2015 8.2.0 released.
catch’s picture

So I think that's a good plan, with one concern that we may have a proportion of majors that can only be fixed in minor releases because they add to the public API or imply small bc breaks for @internal etc. In that case not having 8.1.x open means we can't fix those. But can revisit if it becomes an actual problem.

xjm’s picture

Issue summary: View changes
Status: Active » Needs review

Cool, adding the proposal to the summary.

MustangGB’s picture

So I understood the proposal, but then got confused when the suggested timeline dates didn't match.

Proposed beta after 4 months, timetime beta after 3 months
Proposed rc after 5 months, timeline rc after 4 months
Proposed release after 6 months, timeline release after 5 months

Is this because you want to get back onto an April/October 6 month release schedule, rather than a May/November one? Or was it an oversight? Or something else?

xjm’s picture

Issue summary: View changes
FileSize
10.36 KB

@MustangGB, yes, the Drupal 8 committers discussed this previously. In general, we plan to release scheduled minors around April or May and around September or October, to avoid having releases during either the summer or winter holidays. However, we also do not want to have releases too close to a DrupalCon. Therefore, for 8.1.0, we've been tentatively planning on mid- to late April just 5 months after 8.0.0. This also has the advantage of being able to add a few new features a little sooner, because Drupal 8 has been in feature freeze for three years now.

It's not formally decided yet, but April 20 is the date we've tentatively been discussing since that is already a release window. The other dates are also release windows. (The mid-February date is moved a week later so that it is not during DrupalCon Asia.) So that's where those dates came from.

Thanks for checking!

Attached is an illustration of the proposed dates.

xjm’s picture

Issue summary: View changes
xjm’s picture

Title: [Policy, no patch] 8.1.x release schedule » [policy, no patch] 8.1.x release schedule
Issue summary: View changes
FileSize
19.31 KB
xjm’s picture

Issue summary: View changes
FileSize
19.32 KB
xjm’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes
catch’s picture

Just realised we never discussed this, although it's been in the back of my head for months now:

I think we should consider the last 8.0.x release (let's call it 8.0.6) coming out on the same day as 8.1.0.

We drop support for 8.0.x as soon as 8.1 is out, but 8.1, even if we stick perfectly to our bc promise, is still likely to break some sites in some way (i.e. with custom code relying on @internal stuff, or a contrib module doing the same).

If we release 8.0.6 the same day, then you can run that release for a couple of weeks, before updating to 8.1.0 (and before the next 8.1.0 bugfix or security window).

Otherwise, 8.0.x support effectively stops on the last window before 8.1.0 gets tagged.

If there's nothing noteworthy in 8.0.x between 8.0.5 and what would be 8.0.6, then we could just not do it - or tag it with no changes - not a big deal either way in that case.

This is similar thinking to having the 6.x EOL date the same day as a security release window - just in case there's something we'd really want to do a final, last ever release for before finally dropping support.

webchick’s picture

Going off the issue summary only, I have a large concern around the management of technical debt blocking product innovation. Smells a lot like thresholds to me, and we have demonstrative proof that thresholds lead to people hiding technical debt so as not to get in other contributors' way. Drupal doesn’t live or die by the # of major bugs it has. It lives or dies based on whether it stacks up to its competition, whether its design is modern/user friendly, etc. So I'd feel better if that commitment was stated up-front. Maybe as a more nuanced view of what "opens for development" means (e.g. "official" initiatives vs. random crazy and wacky ideas).

xjm pointed out that we had discussed this in Barcelona and agreed to use core committer discretion on certain high-impact features, but our commitment to innovation needs to be a lot more explicit in the graphic/date table.

xjm’s picture

Issue summary: View changes

Apologies, that was not my intent in the proposal at all. I replaced with these words:

8.1.x may open for new development, at committer discretion, based on pending prioritized features and critical and major technical debt

xjm’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes

It now reads:

8.1.x may open to new feature development, at committer discretion, based on pending prioritized features and critical and major technical debt. Note: some minor-version-only bug fixes and prioritized features may be committed to 8.1.x before this date.

@webchick, does that address your concern? We can announce the details of the branch management separately.

xjm’s picture

Issue summary: View changes
xjm’s picture

I also added a note to the release cycle overview about unscheduled minors:
https://www.drupal.org/node/2383987/revisions/view/9126996/9127358

xjm’s picture

Also, I should point out that while I agree Drupal does not succeed or fail based on the number of major bugs, it does succeed or fail based on the nature of those bugs. Many majors are critical for many sites and prevent D8 adoption, including usability bugs that must be targeted against minor versions due to UI changes. Those usability bugs would be eligible for commit before the date indicated as well.

andypost’s picture

Maybe as a more nuanced view of what "opens for development" means (e.g. "official" initiatives vs. random crazy and wacky ideas).

+1
having a "plan" issue should be a requirement, that will help a lot to point /contribute into needed places easily

xjm’s picture

Agreed @andypost.

I'm also in favor of the final 8.0.x patch release on the day the next scheduled minor is released as described by @catch.

I propose describing the pink dev phases on the graph as "open feature development phases". That describes the area of development that we would restrict at committer discretion. On Thursday the committers discussed starting to use the 8.1.x branch immediately, before that phase begins, for a few reasons:

  • It allows us to commit bugfixes that are too disruptive for a patch release straightaway.
  • The dev branch can also be used to give us time to test fixes for upcoming patch releases (reducing the risk to production sites) without needing unnecessary commit freezes. E.g., a few days before a patch release window, we would commit to 8.1.x only and wait until after the patch release to cherry-pick them to 8.0.x.
  • Certain important 8.1.x-targeted improvements, particularly for Migrate, do not make sense to block until January.

The question is then, what specifically can go into 8.1.x before that Jan. 6 date? I'd propose:

  • Any bugfixes that are too disruptive or ineligible for patch releases as per https://www.drupal.org/core/d8-allowed-changes#minor
  • Potentially tasks and additions that would have qualified as prioritized changes for the beta: usability, accessibiliy, performance, and security improvements, etc.
  • Any self-contained, complete improvements to certain priorities at committer discretion. For 8.1.x, these would be Migrate and testing infrastructure improvements.
xjm’s picture

Oh, regarding the "final" patch releases for (e.g.) the 8.0.x series when we release 8.1.x. The current schedule actually has the minors coming out on security release windows, not bugfix release windows. Probably we should not actually release bugfixes on that day in order to ensure the security release window meets its goal?

So then we could either:

  • Not do that final patch release, or
  • Release 8.0.LAST and 8.1.1 on the next bugfix window 2-3 weeks later.
catch’s picture

Was thinking similar - final patch release and 8.1.0 happen on the security window 8.0.last only happens if it's a security release for both versions. 8.1.0 is then going to be bugs and security at once, but that's fine.

Then you get a full month before the next security release window to update to 8.1.x.

If there's no security release, then you're OK staying on whatever became 8.0.last until the next one anyway - still get that month.

That would give us a bit of flexibility if a security release requires a deprecation or other disruptive change - could do 8.1.0 and 8.2.0 the same day - with 8.1.0 being really 8.0.last and the sec release only.

None of that would stop us still doing a bug release two weeks later although I can't see loads of benefit unless it was some kind of paper bag fix.

The big thing for sites is when the last 8.0 security release is (if there's stuff to go out). The last bug fix we can just not do if there's not enough to warrant it, but having it in mind to maybe do one two weeks after 8.1.0 seems a good option.

xjm’s picture

Status: Needs review » Reviewed & tested by the community

@Dries signed off on this verbally awhile ago. I've incorporated the schedule here:
https://www.drupal.org/node/2383987/revisions/view/9182874/9229424

catch’s picture

Coming back on the security release, have discussed this a bit with xjm in chat as well, and e-mailed the security team the same thing:

- we should always release minor versions on a security window
- if there are core security fixes to go out, we will release a final patch version of the current minor branch that only contains security fixes (same as we would for any other security window so that people can update immediately without having any other changes)
- the .0 of the next minor branch should obviously also contain the security fixes

Then this gives people until the next security window to get from 8.X.x to 8.X+1.x - which should normally be at least four weeks, which should be plenty of time to test the new minor on a site and resolve any issues. On that security window, only 8.X+1.x gets the security fixes so 8.0.x is properly unsupported by then.

catch’s picture

Status: Reviewed & tested by the community » Needs review
xjm’s picture

We also discussed avoiding making a security release on that window at all, in order to avoid the problem. In most situations, we have a lot of control over when security releases go out. The exception would be in case of an urgent situation like an exploit in the wild.

jweowu’s picture

Just to come back to this:

while I agree Drupal does not succeed or fail based on the number of major bugs, it does succeed or fail based on the nature of those bugs

The question that xjm's quoted comment raises for me is this: Does anyone honestly feel that they have a decent understanding of the nature of the major bugs in Drupal 8? With more than 500 "bugs that have significant repercussions but do not render the whole system unusable", I simply don't know how anyone can see the wood for the trees. In the absence of such an understanding, I can't see how anyone would establish whether Drupal was succeeding or failing.

To me this suggests that Drupal 8 is not in a good state at the moment.

If there were a few dozen major bugs instead of a few hundred, it would be feasible to have a solid overview of what sort of state the product is actually in. To my mind a concerted focus on bringing major bugs under control would bring confidence in the state of the product in a similar fashion to the way that automated tests brought confidence about individual changes.

I just don't see how anyone can feel confident about Drupal 8 right now. Am I missing something?

cilefen’s picture

Drupal is a big OSS project and there has been concerted focus on major issue triage, see https://www.drupal.org/node/2474049. Maybe we could encourage more sprinting on that.

catch’s picture

@jweowu

So I think you are missing some things, but I also agree with the general sentiment that it's impossible to know what the actual health of Drupal 8 is when the issue queue is in the state it is.

However exactly because the queue is in such a bad state, what we actually have is several hundred major bug reports which have not properly triaged yet, and probably a couple of hundred actual major bugs if we went through the same process we did for critical issues over the past couple of years (which were also well into the hundreds during both Drupal 7 and Drupal 8's release cycles).

So of the 500+ issues:

  • Some of them are bugs, but they aren't major at all - should be normal
  • Some of them are refactoring tasks that were filed as bugs (i.e. 'this API is annoying to work with'), which then might be either normal or major, but not bugs
  • Some of them are duplicates of each other, or of issues that have already been fixed

Additionally, there are many components in Drupal core that will only be used on a fraction of real sites. So the sqlite database driver's three major bugs probably affect a fraction of a percent of sites. Tracker and statistics have one major bug each but most sites I've worked on didn't use either module. There are ten major bugs against simpletest.module - which might or might not be major, but don't affect production code at all.

Also many issues affect Drupal 7, and in some cases were discovered before Drupal 6 or 7 were released - so while bad, we've been living with them for a long time and they're not new to Drupal 8.

So in terms of a concerted effort to get them under control, the first thing we need to do is triage them (all of them, then keep on top of new ones as they come in). This is already happening, but it's probably at best keeping things even rather than making a dent in the total.

I've opened #2645692: [policy, no patch] Update priorities/categories of issues and core components to assist triage to discuss this a bit more.

cilefen’s picture

@jweowu Here is an example of an issue that opened as a major but which needs triage: #2625660: Meta description and forum.

xjm’s picture

I think #33 all makes sense, but on the other hand... I realized an inconsistency this morning with using the security release windows for the minor. We set March 16 as the beginning of the 8.1.x RC phase, but 8.0.x has a bugfix release on April 6. That doesn't make sense; we would not put bugfixes into 8.0.x but not 8.1.x.

So the RC for 8.1.x should start on a patch release window, April 6, instead. We could choose to create two release candidates, one each week, or as needed in case of critical or RC target fixes that come in.

Then, if we are moving the RC date to April 6, does it make sense to have 8.1.x in beta for 6 weeks, or should we move the date of the beta up to March 2 as well? I think that could make sense, especially since this was already a shorter minor cycle. I don't think we should move 8.1.0 at this point. We can discuss whether to move 8.2.0's proposed date.

catch’s picture

Then, if we are moving the RC date to April 6, does it make sense to have 8.1.x in beta for 6 weeks, or should we move the date of the beta up to March 2 as well? I think that could make sense, especially since this was already a shorter minor cycle.

I think it makes sense to move the beta. We don't have massive new 8.1.x changes that need testing, and individual changes could still get pushed to 8.2.x if there's not enough time to test them before 8.1.0, but that's not going to be the majority of 8.1.x fixes that would otherwise get caught by an RC freeze at the moment.

xjm’s picture

Issue summary: View changes
xjm’s picture

I'll update the handbook page with those dates.

For 8.2.x and going forward, I think there are a couple competing requirements:

  • We do not want to release during, or too near to, a DrupalCon. Dublin is September 26-30 (extended sprints might go until Oct. 1-2).
  • The release candidate for the next minor (8.2.x in this example) should be released on the same day as the final bugfix release for the current minor (8.1.x).
  • There needs to be sufficient time for sites to upgrade between minors before any SAs are disclosed without there being an 8.1.x sec release (at least a month), because while public APIs are stable, internal APIs may break (including form arrays, etc., meaning that module- and site-specific form alters need to be updated, among many other things) and user interfaces may change (which affects sites or modules that need to theme or alter those user interfaces).

That means we have a choice between:

  1. Releasing the minor on the patch release window, and a final security release for 8.1.x as needed. (I know David had some concerns about this, both concerns about update manager not recommending the right version of 8.y.x and about overhead for creating the sec releases.)
  2. Releasing the minor on the patch release window, and not using the following security window except in case of an urgent fix. We could encourage people to begin testing the update during the RC phase, but a majority will not upgrade until Update Manager tells them to.
  3. Providing a patch for 8.1.x and committing it to the branch, but not creating a new release.
  4. Having an RC phase of only 2 (or at most 3) weeks for minor releases, with the minor and a final 8.1.x release on the security window as per @catch's proposal above. (I actually think this also risks David's concerns in #1, at least the Update Manager part as well as forcing us to deal with a sec release on the same day we're rolling a minor.)

Based on all these things, I'd recommend one of:

OPTION A
Sept. 7 is the final patch release for Drupal 8.1.x and the beginning of 8.2.x RC. If needed, a security release of 8.1.x (as well as a new RC of 8.2.x) are created on Sept, 21. 8.2.0 is released on October 5. We eliminate the October 19 security window unless the SAs are D7-only.
OPTION B
Sept. 7 is the final patch release for Drupal 8.1.x and we make it clear 8.1.x will not receive further bugfixes other than security fixes. Patches are only committed to 8.2.x+ after that point. However, we don't start the 8.2.x RC phase until Sept. 21. We eliminate the October 5 patch release window (or only use it for Drupal 7), and release 8.2.0 on October 19, releasing it only after any 8.1.x security release goes out earlier in the day (and patching it for those fixes immediately before release, which still means we have to have both an 8.1.x and 8.2.x patch ready on the security issue). We still avoid creating a security release on that day if possible.
xjm’s picture

Status: Needs review » Reviewed & tested by the community

@catch and I agreed on option A. I've updated the doc: https://www.drupal.org/node/2383987/revisions/view/9361280/9364530

I think this can be RTBC again based on that.

Anonymous’s picture

> ... Drupal 8 has been in feature freeze for three years now. ...

One non-Drupal-dev's view. Posted here, as it's really not clear to me where ELSE to have this discussion.

Drupal core certainly marches steadfastly forward. That's great to see.

Reading the above, there's knowledgeable comment & concern about the 'state' of things. Mention's made about Drupal 'living & dying' by its bugs, by its usability, etc etc.

But, "simple endusers like me" read all of that, and, to be quite frank -- have not the slightest clue when we can legitimately plan on a working, performant Drupal 8.

Weeks more? Years more?

To be very concrete in my example, a straightforward install of

drupal 8.0.3 + a "reasonable collection" of mods (i.e., had it before, frequently/commonly use similar mods/capabilities on other systems, etc) of mods,

admin_toolbar
backup_db
big_pipe
deploy
git_deploy
imagemagick
pathauto
purge
redis
search_api
search_api_solr
security_review
smtp
ultimate_cron
varnish

is barely installable today, let alone functional, robust & well-documented.

And, why those? Simply because, in my sphere of influence, that's a working, deployable system that I can 'drop' on a client, and not have to make excuses for -- vis-à-vis prior Drupals or current competition.

As @webchick,

> Drupal doesn’t live or die by the # of major bugs it has. It lives or dies based on whether it stacks up to its
> competition, whether its design is modern/user friendly, etc.

My unsolicited $0.02? -- I couldn't agree more.

I read about the Drupal 'module acceleration' efforts (whatever the initiative is called ...), and that's great to see. Certainly recognize the limits of resources.

Guess I have a simple question ... who, if anyone, looks at the 'functional completeness' of a "real world system" ? Not just core, and not just individual modules, but the ecosystem (sure, let's argue about what that is ...) that makes up a working/modern install.

Where is that discussion being had?

catch’s picture

Status: Reviewed & tested by the community » Fixed

https://groups.drupal.org/node/508968 was published. So marking this fixed.

@bugsonly this issue is about release dates for 8.1.0 so it's really not the right place for that discussion.

https://dev.acquia.com/blog/drupal-8/announcing-the-drupal-8-contrib-por... is the 'module acceleration' effort mostly. There are links from there to projects tracking the status.

What makes up the 'must have' list of modules for sites depends on what the site is and who's building it. I haven't used git deploy for years for example (either extract tarballs and check them into git directly, or use composer to handle that). Several of the most-used modules in 7.x (views, large parts of features and ctools, entity reference etc. etc.) were either moved into 8.x or made redundant by it, so my hope is that 8.x will end up with a less of a ski slope of module usage overall.

catch’s picture

Anonymous’s picture

@catch

> it's really not the right place for that discussion.

fair enough. but, srsly ... sigh.

> What makes up the 'must have' list of modules for sites depends on what the site is and who's building it.

My #1? I'd settle for "high performance caching". Varnish anyone?

Thx, tho! Mv'ing ... somewhere else ...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.