+0 I'm not thrilled since:
- it will put pressure on the RMs (there are several steps additional done
for final releases + the ci needs to be shiny perfect + increases the
number of jobs and branches for versions + branches for partial features);
- in theory all the releases should be tested fully (before we had a buffer
to catch bugs between Ms + more time for the community to test the
releases) and
- the roadmap items planning might need more issues/bureaucracy.
Also users might be confused about the 'quality'/frequency of releases and
they might adopt strategies like installing even/odd release version or
just bugfix releases. So I'm not sure this will fix use case in terms of
users feedback.
It's just a feeling I have and I'm a bit worried since our community is
small, but maybe I'm just resistant to change. I'm willing to try though.
I would prefer 10 releases N.0 to N.9 (just for 'esthetic' reasons). Also I
would have prefer to start this new version/release scheme for the 9.x
cycle, instead of butchering the 8.4+ stabilization releases (for
'consistency' reasons).
Thanks,
Caty
On Thu, Sep 15, 2016 at 12:18 PM, Vincent Massol <vincent(a)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.
WDYT?
Here’s my +1 to try this.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs