Result: +1 vincent +0 caty +1 marius +1 thomas +1 guillaume The vote is passed.
I’ve now updated our doc at http://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractices Let’s start applying this for 8.4 now. Thanks -Vincent > On 15 Sep 2016, at 11:18, Vincent Massol <[email protected]> wrote: > > 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 > integration). > * Less need for bugfix releases of stable versions. For LTS it’s still > required though. > * 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. > > When: > * 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. > > WDYT? > > Here’s my +1 to try this. > > Thanks > -Vincent > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
