+1 Let's try.


On Thu, Sep 15, 2016 at 12:18 PM, Vincent Massol <vinc...@massol.net> 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.
> Here’s my +1 to try this.
> Thanks
> -Vincent
> _______________________________________________
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list

Reply via email to