On Thu, Sep 15, 2016 at 11:47 AM, Ecaterina Moraru (Valica)
<vali...@gmail.com> wrote:
> Also the design for our Download page might not be optimal with this
> change. Users will have to go more to the Other versions if they will be
> 'recommended' a particular version (just like I said if they will adopt
> some odd/even or  divisibility by 5 rule, etc).
>
> Thanks,
> Caty
>
> On Thu, Sep 15, 2016 at 12:40 PM, 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 + 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.

We still have LTS for this. Like before users want to be safe will install LTS.

>>
>> 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 <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.

+1

>>>
>>> Thanks
>>> -Vincent
>>>
>>> _______________________________________________
>>> devs mailing list
>>> devs@xwiki.org
>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>
>>
>>
> _______________________________________________
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs



-- 
Thomas Mortagne
_______________________________________________
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Reply via email to