Hi devs,

Executive summary:
* Replace our 3 month release cycle by a 1 month release cycle.

Needs and advantages:
* Be able to get our changes faster to our users. Importantly, bugfixes are 
released faster to users. Note: it’s not because we release faster that our 
users have to upgrade as fast. They can skip some versions if they want/need.
* Be able to get more feedback more quickly from users. Right now, most (if not 
all) of our users are testing only final versions. They’re not testing 
milestones or RCs and thus we usually only know about problems after the final 
has been released and we incorporate the change in the next one (to be released 
3 months later) or we have to do a bugfix release.
* Get closer to cloud needs. Nowadays, could offerings happen more and more and 
operating a cloud means bringing improvements and fixes as fast as possible. 
Some software in the cloud are even updated/patched several times per day. 
We’re not there yet but we’re trying to get closer by reducing from 3 months to 
1 month
* This also means more marketing for the xwiki project since other site relay 
the new whenever a final version is released

Proposal Details:
* 1 month split in: 3 weeks to release a RC + 1 week to release the final 
version. It’s very important to keep the RC as a meeting point and ensuring all 
is going to be ready on time for the final release (jiras are closed or moved 
to the next release, CI is passing, documentation and RN are ready, etc).
* Split large features into smaller chunks. It doesn’t matter if some code is 
released but unused for example (provided the build is passing). For larger 
refactoring that absolutely cannot be split into 3 weeks chunks (I’m not sure 
that really exists) then we can use branches (and create a CI job to ensure 
* Less need for bugfix releases of stable versions. For LTS it’s still required 
* Note that this 1 month release strategy will not generate more releases (and 
thus more work) over the year since we’re already releasing every 2-3 weeks ATM 
(milestones, RCs, et)
* Version Naming: from N.0 to N.10 where N is the cycle name. The reason for 11 
releases and not 12 is to account for slippages + potential bugfix release at 
the end of the cycle for stabilization + holidays. We might even be able to do 
only 10 releases and not 11 but I’m suggesting we try with 11 for now.

* I’m proposing to start this process with the 8.4 release (starting on the 
10th of October). Since that version is already supposed to be a stabilization 
release (and thus a short 1 month release) it’s not going to change anything. 
We should also do bugfix releases after 8.4 is releases: 8.4.1, 8.4.2, etc till 
the end of the year
* Then starting 9.0 we really start doing 1 month releases.


Here’s my +1 to try this.


devs mailing list

Reply via email to