We've been able to consistently release new features and refactoring on the six month cycle, with relative success on minimising disruption for contrib/custom modules and websites, however there are some limitations we're hitting with the six month cycle that we feel a four month cycle might be able to smooth out.
Currently, given time for alpha, beta and rc releases, issues that narrowly miss the beta window have to wait eight months to get into a tagged release.
This mostly affects two kinds of patches:
- experimental modules (usually associated with an initiative), either being added to tagged releases for testing purposes or nearing stability.
- bug fixes that are potentially disruptive or require new API additions, often in order to support contributed modules or themes.
- updates to third party dependencies, we are often 5-13 months behind Symfony minor releases, partly due to offset between release dates.
- updates for compatibility with new PHP 7 versions, for example PHP 7.2 will be supported by 8.5.0, more than four months after PHP 7.2 was released.
These kinds of patches missing the release window means while they can be committed to the development branch immediately, they won't make it into a tagged release for eight months. This creates pressure on the committer team to either commit feature patches to meet the deadline, which spreads committer attention thin at the busiest time of the cycle, or to backport disruptive bug fixes to patch releases or during the beta/rc period so that they're available sooner, which can have a negative impact on stability and/or mean less time for contrib module authors to take changes into account.
On the other hand, minor releases can be disruptive and require contributed module updates, so having more frequent releases could negatively impact the ability of end-users to update their websites promptly and create more frequent work for maintainers. We're therefore additionally suggesting that the support cycle for a minor release be extended to 8 months from the current six, to allow a full minor release overlap for sites to update. This will require supporting two minor branches of Drupal 8 for security at a time, increasing the workload, although in practice we expect most security releases to only require cherry-picking changes between branches.
Release a minor version of Drupal 8 every four months, three times per year compared to the current two.
To give sufficient time for sites to upgrade, support each minor release for eight months, two months longer than the current support period.
The change should result in the following improvements:
- new features and bugfixes will be available in tagged releases sooner
- the effort spent discussing whether or not a patch is backportable since there will be less pressure to backport issues that might be disruptive.
- minor releases will contain a smaller set of changes, assuming the same rate of change year on year
- end users will be able to stay on a minor release for up to 8 months instead of the current 6, allowing a longer window for any contrib or custom code that needs to be updated before security support is dropped.
There are also these trade-offs:
- Since two core branches will be supported at once, contrib modules will need to either retain compatibility with both branches, or add a core version dependency when they want to take advantage of new APIs.
- Additional work for core committers and the security team when preparing security releases.
Other considerations:
Why not 3 months instead of 4?
- currently we have two weeks of alpha, two weeks of beta, two weeks of release candidate, a total of six weeks where the minor release is somewhat frozen to new features before it is tagged. There is a limit to how short a beta/rc period can be to be useful.
Discuss the impact on core contributors, contrib module authors, the security team, site admins and committers and try to figure out if this is a good idea or not.
There is a core conversation proposed for DrupalCon Nashville at https://events.drupal.org/nashville2018/sessions/drupals-innovation-cycl... to discuss this in person as well.
Comments
Comment #2
kim.pepperI really like the idea of more frequent releases for the reasons stated above, especially getting new releases sooner, but also for having more time to upgrade when a new release is out.
Comment #3
gábor hojtsyComment #4
balsama+1 (or possibly indifferent) to shorter minor release cycles
-1 to supporting two minor releases at a time
Supporting two branches puts a burden on module maintainers. I've been thinking about how I might approach this and the only way I can envision it working without adding additional work is to support a single core release for 8 months and leapfrog every other core release. Which obviously isn't ideal.
You could argue that one branch would just need cherry-picked security updates, but A) That's not necessarily trivial and B) It never seems to be that easy. We're constantly improving infrastructure and testing - and that always affects all the moving pieces.
To complicate things more, Drupal.Org doesn't' support semantic versioning for contrib projects. And the packaging systems doesn't expose non-release branches to the packagist further complicating things. Ultimately, these last two points result in crazy high version numbers with sloppy commit histories. Again, not the end of the world, but a burden.
Comment #5
aspilicious commentedAt our company we force our clients to pay for each minor upgrade, to ensure stability and security for their platforms. With the new policy the cost for our clients will increase. Most of them won't care but for some smaller organisations each dollar/euro/... counts.
This issue feels more like "marketing" pressure to get new features out faster... If the unami profile for example wasn't finished in time, just push it to the next release. If that's 6 months later, so be it. The entire backport stuff to force it into 8.5 even if it was to late for beta feels a bit dirty to me... I don't want to install more code that isn't properly working. If there wasn't something like a "drupalcon" in the US in a few months, this wouldn't happen.
Drupal 7 is still shipped with an ancient jquery version, and now we are worried that we can't use php 7.2 when it's released?
We waited a couple of years for drupal 8, we can wait 6 months for some minor features...
Certainly if they are tested properly and have good test coverage.
I'm also afraid that some minor releases won't have any important features at all because of the short time frame.
Comment #6
timmillwoodI like the idea of supporting two minor releases at the same time. We have many D8 sites and only in the last few weeks updated them to 8.4 due to contrib and custom module incompatibilities. We're trying to plan the 8.5.0 release a bit better and start preparing now, but I doubt we'll be ready in 3 weeks time.
Although we're also facing the issue where our custom (and contrib we maintain) modules need to work with 8.4 on some of our sites, and 8.5.0 on the site we want to upgrade first. We might just have to say 8.x-1.8, for example will work with 8.4, but then 8.x-1.9 will require 8.5.0. Although if we have a bug fix we want to add to our 8.4 sites it won't work. Maybe we'll need to use 8.x-1.8 for 8.4 and cut 8.x-2.0 for 8.5.0?
It would be much easier if contrib had proper semantic versioning and they could align with core for example core 8.0.0 with contrib 1.0.0, core 8.1.0 with contrib 1.1.0, core 8.2.0 with contrib 1.2.0 etc.
Comment #7
xmacinfoI have a few question/comments:
Comment #8
jose reyero commentedFrom the issue summary:
Well, we can call it 'relative success' or 'relative failure', both terms are relative enough :-)
The truth is maintaining a D8 site without a dedicated development team is a PITA. So I wouldn't care how often you want to push out new minor releases, it can be monthly if people just can't wait for their new features to get in, but we do really, desperately, need some kind of LTS releases, that should be supported for 1 year at the very least.
Comment #9
catch@balsama:
Yes this is mentioned in the issue summary, but it's the biggest drawback to supporting two branches at a time. Even if core only has to cherry-pick one or two security issues, contrib modules having to support two branches at the same time is much more challenging. We've only just introduced deprecation testing, and improved contrib options for which core version gets tested on d.o, and that would have a further impact with two branches, it's been hard enough to get right with one at a time.
This is also the reason why a mid-major LTS would be incredibly difficult - how many contrib modules are going to maintain compatibility with both 8.5.0 and 8.6-8.7-8.8-8.9?
@aspilicious
We very regularly get major bug fixes that aren't patch-safe, affect contrib modules or are just nasty, and people pushing for them to be committed during beta and release candidate (or two patch releases), so that they don't need to run a patch for 6-7 months or get held up being able to release a stable version of contrib modules.
Four month cycles also mean that if something is started at the beginning of a cycle, and takes five months to get commit-ready, it will be available 8 months after the work started rather than 6, so it doesn't mean that specific feature necessarily get released faster, just that features in general get released more often.
With the same amount of development, there is not going to be a faster feature development rate in one year compared to now, it would be exactly the same, just divided into three instead of two releases. If I cut a pizza into 12 slices instead of 4 there is not more pizza.
@aspilicious:
They could have small features and API additions, and that would be fine IMO.
@aspilicious
If we're able to do an 8 month support cycle per minor release, then they could update three times in two years instead of four times in two years.
Comment #10
wim leersThese seem to contradict.
Thanks for making me look at it this way. That is much clearer.
In a nutshell, this results in:
I'm not yet convinced either way. But re-reading the IS:
IOW: this allows Drupal to better integrate/stay in sync with the fast-moving web ecosystem by adopting more frequent releases. That seems worthwhile.
Comment #11
catch@Wim so I think the quotes in #10 are contradictory because there is an actual contradiction.
The 8 month support per-minor is probably worse for contrib maintainers and probably better for site administrators. Contrib authors have to deal with two stable versions of 8.x, site admins can choose to update more frequently or less frequently (but either way get security updates until they update, as long as it's within 8 months).
One thing we might need to do is to only add deprecation notices two releases after creating a new API.
Release A - add new API.
Release B - no change, but contrib can update to use it
Release C - deprecate old API.
That way the new API is available in both supported releases before it gets deprecated.
For changes which aren't straight new thing/old thing it'd still mean writing code compatible with both though.
It's not a good thing that Drupal 7 ships with an ancient jQuery version, that's why we reversed the policy to allow jQuery updates in 8.x, and jQuery have also changed their release cycle since Drupal 7's release.
PHP has also changed their release cycle, to three years per version - so if it takes us 6 months to support the latest stable release of PHP 7, then that 36 month support cycle ends up in practice 30 months.
Comment #12
aleksipHow about the previous minor version getting only security support, nothing else?
If their site is working well enough, many smaller site owners just want to keep the site running as it is, and are only interested in security support. I'm not sure if just two more months of security support is going to make a big difference for them. Would be a welcome improvement, nevertheless!
Comment #13
drunken monkey+1
I think the biggest question here is whether Core committers and the Security Team would be fine with it – they'd have most of the additional work, as I see it. Especially users, which should be the primary consideration, really seem to have only advantages from this. (At least as long as we explain this well enough, and take care to fix all the release cycle documentation appropriately – otherwise, there could be some confusion.)
As a contrib module developer (which is 95% of my work) there aren't really any advantages, as far as I see it, but also not really any disadvantages I can see. Especially, I don't see how "maintaining support for two versions" would be a problem. We already have that with the dev branch and the stable branch, or even three branches at a time. Needing to wait two months longer to switch to new APIs from deprecated ones doesn't really seem like a problem. (Of course, something like the "deprecation delay" described in #11 would be needed, I guess. (Although, as we currently do both steps in release A, I don't think deprecation needs to wait until release C – release B should be late enough, as all sites should run on versions with the new API at that point. (This will of course lead to some deprecation log messages until contrib modules have new releases with the switch to the new API, but that's the same as now.))) And Core takes good care to avoid breaking BC anyways. (Tests break sometimes, but that's hardly critical.)
Comment #14
catchThis is all we'd do for core, but it still means that contrib maintainers will need to support two stable versions of core at a time - whether by ensuring the module is compatible with both, or having two branches in some cases. For most minor releases for most modules, this isn't actually any extra work (just branch tests running on both) - but occasionally it will be more.
Comment #15
heddnHere's some random thoughts without any specific recommendation.
I'm a contrib module maintainer of several modules that have already gone through 4 major releases to keep in step with core's minor release cycle. Having to support 2 versions is probably not that much harder than 1. Why? Because once the next release comes out of core, the earlier versions of the contrib modules go into minimal support mode. The most time I would spend on them is fixing any security bugs in them. Sure, older versions need support, but let's be realistic. Drupal 7 modules still need support too and are "officially" supported. But in a lot of cases, these D7 modules quickly gather dust. Same would occur here. The real pain point then isn't core or contrib maintainers. It is the consumers of these modules who would feel the most pain. They wouldn't get their features/bugs into older versions unless they provide a patch with everything ready. Tests, high quality code, everything. Everything that is except a lot of time and help from the maintainer. Without any assistance from a maintainer, that means a lot of stuff is going to flounder and never see the light of day for contrib in older releases.
But that's probably OK, because they can just upgrade to the latest core and contrib modules, right?
As a core/contrib dev myself, I would prefer to see faster releases of core. It means worse case scenario, I have to wait 4 months before I can start using those new core features in my contrib modules. Because I'm going to devel my contrib module off those new features. Even if that means I have to develop against HEAD of core. If it were 6-8 months that I had to wait, I'd probably not do that to my contrib module's consumers. But its only a 1, 2 or worse case 4 months. Short enough that I can justify adopting things in contrib faster.
Comment #16
moshe weitzman commentedI think our current 6 month release cycle is relatively understandable. I think this proposal adds complexity. My slight recommendation is to keep the model and encourage folks who are pressing for faster releases to use composer/patches to shore up their sites. In the D6 cycle, Pressflow became the publisher of important patches that you probably wanted. I think an equivalent is needed for d8. Lightning and Commerce are kinda sorta that for folks in the know but a dedicated web site would be clearer. They also can't keep up with core's bleeding edge.
Comment #18
alan d. commentedI don't know the context of what the webchick was doing the interviews for, but she did pick up the point that minor update pain creates a significant negative perception of Drupal with key stakeholders about 6 months back (just before SA-CORE-2018-002).
https://www.drupal.org/project/drupal/issues/2909665#comment-12533496
Personally, I'd prefer to go the opposite direction with a 1 year minor release cycle with at least 6 monthly security support. Mostly to keep the maintenance phase costs down for existing clients we support.
Like moshe stated, it's fairly easy to use composer with cweagans/composer-patches to get the bleeding edge features; or go headless utilising the fairly stable low level core APIs with whatever you want ;)
Comment #27
catchThe original problems this issue was trying to deal with have been coming up less and less, partly helped by opening the next minor release at an earlier stage, and otherwise the six month cycle seems to be the best balance between frequency and workload (both for us as core maintainers and sites/contrib keeping up). So going to close this as 'works as designed').