> On 15 Sep 2016, at 13:23, Ecaterina Moraru (Valica) <vali...@gmail.com> wrote:
> On Thu, Sep 15, 2016 at 1:15 PM, Vincent Massol <vinc...@massol.net> wrote:
>>> On 15 Sep 2016, at 11:40, Ecaterina Moraru (Valica) <vali...@gmail.com>
>> wrote:
>>> +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 +
>> Could you be more specific? I don’t see any change for the RMs.
>>> increases the
>>> number of jobs and branches for versions + branches for partial
>> features);
>> Actually, as I’ve mentioned in my mail, it should decrease slightly the
>> number of branches/jobs since we’ll have less bugfix releases for stable
>> versions. Or keep it similar. But I don’t see an increase.
>>> - 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
>> Yes that’s part of the rational I put: increase the testers and use more
>> the community to test.
>> Our scope has been increasing over the years (more features, more
>> extensions). It’s important to use more and more the community to help us.
>>> - the roadmap items planning might need more issues/bureaucracy.
>> Possibly a bit. But the way I view this is that we’ll continue to do
>> roadmaps every 3 months or so for the coming 3 releases and do the steering
>> every month in case we want to change it slightly.
>>> 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 does. If you’re an existing user and you’re upgrading, say every 6
>> months, it won’t change anything ofc.
>> But if you’re a new user, you’ll be able to use the latest released
>> version. And report feedback, bugs, ideas, etc. You won’t start on a 3
>> months old release.
>>> 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.
>> You do look a bit resistant to change :)
>> But that’s fine. It’s good to have someone playing the devil’s advocate.
>> However, I haven’t seen any real cause for being worried so far.
>> Honestly it's almost is a non event and doesn’t change much IMO. It just
>> means removing the suffix “milestone” from our releases ;)
>>> 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).
>> Could you explain what you mean by butchering? Could you also explain what
>> is not clear in:
>> “[….]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.[…]"
> By butchering I meant having 8.4, 8.5, 8.6, 8.7, etc. and having to explain
> the users that for the 8.x cycle the versioning strategy changed meanwhile
> and 8.7 is equivalent to 7.4 final. But the thing is that I forgot that
> 8.4+ were shorter releases, so I guess you are right: it doesn't change a
> thing. By the end of the year we should have just 8.4 and 8.5.

Actually we’ve decided a while back to no longer have N.5 releases because we 
don’t have enough time at the end and we usually have to carry the remaining 
stabilization/polishing work in the next year.

So the idea is to have 8.4 till around mid November (i.e. 1 month) and then to 
do bug fix releases of 8.4 every 2 weeks, i.e. 8.4.1, 8.4.2, etc.

And then on Jan 2nd, start 9.0.


> Thanks for the explanations,
> Caty
>> So to remind you, the last stabilization release is already meant to be 1
>> month (we’ve been doing this for some time already, even doing it for the
>> last 2 releases in the past when we had a N.5 release), so as I said, it
>> doesn’t change anything.
>> So in practice I could have omitted this part since it’s the same as
>> saying we start only in 9.0 but I wanted to put us in the spirit of the new
>> strategy ASAP.
>> Thanks
>> -Vincent
>>> Thanks,
>>> Caty
>>> 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.
>>>> WDYT?
>>>> Here’s my +1 to try this.
>>>> Thanks
>>>> -Vincent
devs mailing list

Reply via email to