[policy] Adopt a 6-month feature release schedule for Drupal 7 (similar to Drupal 8) and use pseudo-semantic versioning

Regarding branching, I'm not sure if we have the ability to do that in the full-fledged way that Drupal 8 does (i.e., with full drupal.org integration). I could be proved wrong though.

However, I was thinking we would have (at most) around 2 bugfix releases between the 6-month minor releases - just based on where Drupal 7 is at this point we really don't need more than that. So let's say 7.50 comes out January 1, then there might be a bugfix release on March 1 and another on May 1. That would leave two months between May 1 (the last pure bugfix release) and July 1 (the next feature release). So if we held off committing feature patches until then (people could certainly work on them before then, but they wouldn't be committed), we could basically do this without the need for separate branches, and there would still be two months in which 7.x-dev is being prepared for the next feature release.

If there needed to be an emergency hotfix during that two month period for some reason, we could branch that off the previous release (just like we do for security releases), so it wouldn't interfere with the code in 7.x-dev either.

Since 7.9 => 7.10 worked OK I hope that means 7.9x => 7.100 would work fine too, but yes, worth checking just in case :)

I'd like to finish this discussion soon since there are issues (#611294: Refine permissions for Field UI is one example) that would make sense to skip for the next Drupal 7 release and hold off on until the proposed Drupal 7.50 (on April 20) if we're going to have that.

I mentioned this issue on a https://groups.drupal.org/core post in October (which is how it got some community feedback then) but it was towards the bottom of the post. I think I should post a short, dedicated announcement there this week, pointing people to this issue and asking for final feedback.

In the meantime, I put together a quick testing patch (attached) which takes the data from updates.drupal.org and replaces the data for the most recent Drupal 7 release (currently Drupal 7.41) with a fake version that skips some version numbers (e.g. "7.100"). This can be used for manual testing on 7.40 or earlier. I tried it out and everything seems to work fine; it correctly detects the new release and advises the site to update to it. So I believe Drupal 7 Update Manager can support version jumps like 7.43=>7.50 (and can support it beyond 7.100 too), which is one of the issues discussed above.

Regarding the comments about an LTS, I left some more detailed thoughts about that on #2598662: Decide when Drupal 7 (and Drupal 8 and later) should enter the LTS and security-support-only phase at the time, but in short, it doesn't seem to me like Drupal 7=>8 migrations will be fully supported (including contrib modules) for quite a while. As long as there are a lot of sites still running Drupal 7 with no immediate plans to move off of it, I would think it still makes sense to add new features where appropriate. And even bugfixes can sometimes be disruptive (often more disruptive than new features) so if there's a bugfix worth having that seems a little risky, that would be something to hold off for the special 6-month releases too.

I posted the announcement here: https://groups.drupal.org/node/508530

Will this also include triaging issues that are eligible for the next release?

I think there could be a "7.50 target" tag (or similar) that people could apply to issues as appropriate. Personally I would keep an eye on the RTBC queue for these kinds of issues.

I am not against this, but I think there is frustration among some users right now about bugfixes in 7 and the attention that they get (especially ones that got put on hold because of backport policy).... I didn't even try to count the number of Needs Review ones.

What are their concerns exactly? It seems to me like this is a function of the number of people working on Drupal 8 issues + the number of people working on Drupal 7 backports of those issues + the number of people reviewing Drupal 7 patches. So I wouldn't expect it to be affected by this issue.

There are 50+ RTBC issues right now... Having even longer waits may not go over well.

The 50+ issues was just because it was shortly before a release, and I tend to go through and commit things before the release (this maximizes the time for getting reviews... and we are badly in need of more high-quality reviews). So right now the RTBC queue is back down to fewer than 10 issues :) (usually it would be even smaller but a few issues were deliberately held off for one release cycle, partly due to the possibility of us adopting this issue)

It definitely is true that this proposal would mean certain issues (usually not bugfixes, but perhaps some of them) have to wait longer to make it into a core release, rather than always having a shot at making it into the next one. There could be up to a 6 month delay (by design). I am sympathetic to this concern and even raised it myself during the Drupal 8 discussion but ultimately it seemed like people thought that was an acceptable tradeoff for having more well-defined releases.

we are limited only by the maximum string lengths PCRE can match and version_compare can compare... That's significantly more than the number of the atoms of the universe or some other nonsense.

That's good to know :)

It might be helpful to this discussion to have some more concrete examples of current/active Drupal 7 issues that would fall under this 6-month policy.

Here are four examples. There are certainly more out there, but these came to mind. Three of the four are currently RTBC, and the fourth is hopefully on its way soon:
#611294: Refine permissions for Field UI
#2514136: Add default clickjacking defense to core
#1081266: Avoid re-scanning module directory when a filename or a module is missing
#1664602: Allow attributes to be passed to drupal_add_[css|js] (SRI)

I should have posted another update on this issue a while ago, but better late then never. Also by waiting I had a chance to run this by @stefan.r (who is now a Drupal 7 release manager also) and we agreed on the following:

1. The upcoming release will be labeled 7.50, since there are big enough changes in it (some of the issues from #22 plus others) that it really makes sense to highlight it like that.
2. For the future, we can probably aim to do similar "big" releases roughly every six months, but for Drupal 7 it's not necessarily set in stone; if a six month period goes by and there don't happen to be any big enough changes that get committed, we won't have to do a release with the version jump that time.

It's also worth highlighting here that we aren't talking about committing patches that violate the guidelines on making changes to a stable core release; that has been in place for years and it already allows new features to be added (among other things), with its main goal just to try to avoid breaking people's sites regardless of what is added. (A couple of the issues in #22 do stretch the boundaries of that a fair amount, but it's because they are security-related improvements.) So I think if someone wants to change that #2598662: Decide when Drupal 7 (and Drupal 8 and later) should enter the LTS and security-support-only phase is still the relevant issue to discuss it. This issue however is mostly just about better organizing the kinds of patches we already commit into meaningfully-themed releases, so that what a release will contain is more predictable and better-communicated.

In terms of the timing of releases:

• 7.50 is going to be a bit of a trial run for this, as the first one. Obviously it did not come out on April 20 as I originally hoped :)
• But it's actually better not to do these on the same day as a major Drupal 8 release since that way there won't be "competing" front page announcements.
• Maybe we can try to bring future ones a bit closer to the Drupal 8 schedule, e.g. December for (a possible) Drupal 7.60 which is five months rather than six months?
• It's not clear to me yet how much people care about having a fixed date which is known well in advance, vs. just knowing that it's approximately going to be in six month windows?

Putting this at RTBC for now for any additional feedback. There may be a couple small documentation changes to make for this (on drupal.org) although I think not many.

Figuring out if we can do multiple development branches for Drupal 7 is maybe a good followup issue? (Personally I tend to think it's not worth the effort/burden though.)

Oops, I forgot there was a test patch posted here. But there's nothing to commit :)

Well, it's essentially just starting to happen with this release, so hopefully my announcement at https://groups.drupal.org/node/512445 basically covers that.... (And we'll repeat something about it in the actual release notes/announcement itself too, when the release is made.) But yes, we probably started using the "Drupal 7.50"-related tags a little too early - or rather I updated this issue a little too late :)

The existence of this discussion was also previously announced a couple of times on https://groups.drupal.org/core.

I'm not sure how much more of an announcement or documentation changes we need beyond the above - that's one of the things to look into more before closing this issue. We probably do want to make sure there isn't any documentation that implies releases can never "skip" a version number... but beyond that it sounds like it's going to be somewhat informal exactly when a release comes out that does that (even if the rough aim is to do it on 6-month intervals).

Well, Drupal 7.50 is already out today: https://www.drupal.org/blog/drupal-7-50

However, we have not actually committed to doing more of those in the future.

I don't see this as that much of a direction change, because deciding between committing a patch today and putting it in a release called "Drupal 7.51" vs. holding off and committing the same patch a few months from now and putting it in a release called "Drupal 7.60" is for the most part just a release management decision.

The version jump is of course noticeable, but that's part of the point - it communicates some information about what to expect with the release. (And we definitely know from #2135189: Proposal to manage the Drupal core release cycle and elsewhere that people very much like the idea of more meaningful release version numbers...)

But in any case, would be interesting to hear any such feedback. (That is one reason this issue has had the "Project governance" tag from the beginning.)