> On 10 Dec 2018, at 12:14, Eduard Moraru <[email protected]> wrote:
>
> Hi,
>
> On Sun, Dec 9, 2018 at 5:07 PM Vincent Massol <[email protected]> wrote:
>
>> Ok, summarizing again after feedback from Simon, Caty and Marius, here’s
>> the proposal;
>>
>> * Duration: 11 minor releases (e.g. N.0 till N.10), one each month, from
>> January to November.
>> * The last month of the year, December sees 2 bug fix releases, to
>> stabilize the cycle: N.10.1 and N.10.2. The releases are supposed to
>> contain mostly bug fixes.
>> ** Note that the N.10.2 release can happen on the first days of January to
>> account for end of year holidays but it should not go beyond the 3rd of
>> January.
>> ** Work for N+1.0 starts once N.10.2 has been released.
>>
>
> Note that, AFAIU, work for N+1.0 *can* actually start beginning with
> December, i.e. once N.10 is released and the master branch becomes
> N+1.0-SNAPSHOT. However, the main focus *should* go on the N.10.x
> stabilization branch until EOY (N.10.2).
Yes, the reason I’d prefer to start the work for N+1.0 only after N.10.2 is
released is because I feel it’s better to have everyone focused on N.x and to
make sure it’s as good as it can be (rather than starting working on N+1.x).
Also it mean everyone helps, including fixing the build, etc.
Thanks
-Vincent
>
>> * When N.10.2 is released we announce it:
>> ** Send mail mentioning that the cycle is over and encourage users to
>> start using N.10.2
>> ** In that mail, explain all the major features that were implemented
>> during that release cycle (make a special Release Notes for a Cycle)
>> * We announce the new LTS (N.10.x) once N+1.0 is released. Rationale:
>> ** We need to have feedback on a release before it can be considered super
>> stable and thus we usually need a few bug fix releases before a version can
>> be considered a good LTS. This gives us one month to release additional
>> bugfix releases for N.10.x in case it’s needed.
>> ** This also allows us to always support 3 branches:
>> *** LTS branch
>> *** Stable branch
>> *** master (latest SNAPSHOT)
>>
>> Note that I hesitated to announce the LTS when we released N.10.2 but
>> after thinking about it, I think it’s better to continue announcing it only
>> when N+1.0 is released (i.e. at end of January).
>>
>> I have modified
>> https://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractices?viewer=changes&rev1=14.1&rev2=15.1
>> already.
>>
>> Once I have the final validation this is ok, I’m redo the screenshot at
>>
>> https://dev.xwiki.org/xwiki/bin/download/Community/VersioningAndReleasePractices/releasecycle.png
>>
>> Thanks
>> -Vincent
>>
>
> +1.
>
> Thanks,
> Eduard
>
>
>>
>>> On 19 Nov 2018, at 17:13, Vincent Massol <[email protected]> wrote:
>>>
>>> Hi devs,
>>>
>>> Some devs mentioned it’s too hard to release the N.11 release since it
>> happens around Christmas every year.
>>>
>>> Here’s a proposal:
>>>
>>> * Shorten the cycle to 11 releases instead of 12.
>>> * Release N.9 at end of Nov
>>> * Release N.10 at end of first week of Jan. Note: N.10RC1 would be
>> released mid December (about 17th of Dec to have 3 weeks of RC).
>>> * Release N+1.0 at end of February. Start of N+1.0 work
>>>
>>> Pros:
>>> * No release during Christmas, yeah :)
>>> * More time to prepare the first LTS bugfix release, i.e. N.10.1, which
>> can be done during the month of January.
>>> * More time for the first released of N+1 (i.e. N+1.0). This is
>> important since that’s the release where we can do heavy refactoring and
>> it’s not bad to get some more time.
>>>
>>> Cons:
>>> * One less release
>>>
>>> WDYT? Do you see other cons?
>>>
>>> Thanks
>>> -Vincent
