[Proposal] Change of XS Cycle strategy to account for Christmas

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

[Proposal] Change of XS Cycle strategy to account for Christmas

vmassol
Administrator
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

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Change of XS Cycle strategy to account for Christmas

Thomas Mortagne
Administrator
+1
On Mon, Nov 19, 2018 at 5:13 PM Vincent Massol <[hidden email]> 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
>


--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Change of XS Cycle strategy to account for Christmas

vmassol
Administrator
In reply to this post by vmassol


> On 19 Nov 2018, at 17:13, Vincent Massol <[hidden email]> 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

^^^

I forgot the end of the sentence:

Start of N+1.0 work will be when N.10 final is released, i.e. at beginning of second week of January.

Thanks
-Vincent

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

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Change of XS Cycle strategy to account for Christmas

Eduard Moraru
In reply to this post by vmassol
Hi, Vincent.

+1 for the general goal of avoiding needless holiday stress.

Now, on the details, there is something I'm struggling to understand:
* I see that we have 2 options for finishing N.11:
A) In the middle of December (i.e. 10.11RC on 10th of Dec -2w- and 10.11
Final on 17 Dec -1w-), similar to what we did for 9.11.x (9.11RC1 was on
11th of Dec 2017 and 9.11 Final was on 18th of Dec 2017)
B) At the beginning of January (i.e. 10.11RC on 17th of Dec -3w- and 10.11
Final on the 7th of Jan 2019 -3w-)
** I would personally prefer A) in order to "close the books" before the
holiday season and start fresh in January. Anyone working during the
Holidays can start on N+1.0 or work on bugfixes for N.11.1.
* In both cases, N+1.0 should be same at the end of January, not February.
** Why would it have to be end of February, and thus lose a release, as
mentioned in your "Cons" section?
** I get it if it comes as a new proposal to double the length of N.0 to 2m
instead of 1 (for which I'd be +0, since I prefer less exceptions, if
possible), but I don't get it if we see it as a consequence of how we
handle holidays.

Side note: While trying to understand how all of this works, I can't but
help to notice how the week-based calculations don't add up, since a month
is 4.3(3) weeks long and everything planned around weeks is bound to be
distorted when you look at it by months. IMO, it would make more sense to
reason in terms of months (synchronized with our 12 releases cycle) and say
things like "last Monday of December". Not sure how easy it would be to
work with... just food for thought.

Thanks,
Eduard



On Mon, Nov 19, 2018 at 6:13 PM Vincent Massol <[hidden email]> 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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Change of XS Cycle strategy to account for Christmas

vmassol
Administrator
Hi Edy,

> On 19 Nov 2018, at 19:15, Eduard Moraru <[hidden email]> wrote:
>
> Hi, Vincent.
>
> +1 for the general goal of avoiding needless holiday stress.
>
> Now, on the details, there is something I'm struggling to understand:
> * I see that we have 2 options for finishing N.11:
> A) In the middle of December (i.e. 10.11RC on 10th of Dec -2w- and 10.11
> Final on 17 Dec -1w-), similar to what we did for 9.11.x (9.11RC1 was on
> 11th of Dec 2017 and 9.11 Final was on 18th of Dec 2017)

> B) At the beginning of January (i.e. 10.11RC on 17th of Dec -3w- and 10.11
> Final on the 7th of Jan 2019 -3w-)
> ** I would personally prefer A) in order to "close the books" before the
> holiday season and start fresh in January. Anyone working during the
> Holidays can start on N+1.0 or work on bugfixes for N.11.1.
> * In both cases, N+1.0 should be same at the end of January, not February.
> ** Why would it have to be end of February, and thus lose a release, as
> mentioned in your "Cons" section?
> ** I get it if it comes as a new proposal to double the length of N.0 to 2m
> instead of 1 (for which I'd be +0, since I prefer less exceptions, if
> possible), but I don't get it if we see it as a consequence of how we
> handle holidays.
>
> Side note: While trying to understand how all of this works, I can't but
> help to notice how the week-based calculations don't add up, since a month
> is 4.3(3) weeks long and everything planned around weeks is bound to be
> distorted when you look at it by months. IMO, it would make more sense to
> reason in terms of months (synchronized with our 12 releases cycle) and say
> things like "last Monday of December". Not sure how easy it would be to
> work with... just food for thought.

Some comments:

1) We already work by months, see https://www.xwiki.org/xwiki/bin/view/Roadmaps/#HXWiki10.xCycle. When we plan a given release we adjust (a bit more days or a bit less days) so that it’s released before the end of the month.

2) If I sum up your proposal A) it’s about saying that the last release would be shorter than the other ones. Say half a month vs one month (we can’t guarantee 3 weeks vs 1 month IMO since there can be delays for the previous release, people on early holidays, etc).

Pros and cons of option A vs option B:

* More logical, feel nice to have 12 releases for 12 months and to “fully” finish the N cycle before new year starts (in practice it’s false, see below).
* More stressful, little margin for error and less time for the last release
* No time at all planned for the bug fix release we need to do for the LTS. That’s the biggest issue for option A and what we saw in practice over the past years: we start the new cycle at beginning of Jan and at the same time we have to do the bug fix release for the LTS. In practice this usually means that N+1.0 has little progress in it.

Note that what we did in the past was slightly different:
* We planned for 11 releases (and not 12).
* We said that the end of the year (last month) was 2 stabilization releases of 2 weeks each (no RCs).

IMO if we want to fully finish by end of year we need to include at least one bugfix release for the LTS before the end of the year, which means stopping the dev at end of November (i.e. N.10) and then do a first bugfix release (N.10.1) for mid December and a last bugfix release (N.10.2) from Mid December to early January (2nd or 3rd of Jan).

I am under the impression that option B) (the one I proposed) would be less stressful. It comes at the expense of 1 release less but I’m not sure that this would be a huge issue.
 
@Devs: what would you prefer?

Thanks
-Vincent

PS: We need to hurry to decide if we want to put this in place in the coming days… Might be too late already for some options.


>
> Thanks,
> Eduard
>
>
>
> On Mon, Nov 19, 2018 at 6:13 PM Vincent Massol <[hidden email]> 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
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Change of XS Cycle strategy to account for Christmas

Simon Urli
Hi all,

I'm ok with the first proposal to reduce at 11 releases instead of 12.
I think it allows indeed to better polish the latest release and avoid
lot of stress at the end of the year.

Now on the implem I'd agree more on your last mail, ie:

 > stopping the dev at end of November (i.e. N.10) and then do a first
bugfix release (N.10.1) for mid December and a last bugfix release
(N.10.2) from Mid December to early January (2nd or 3rd of Jan).

than with your first one:

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

So +1 for 11 releases, the 11th released at the end of november and then
december is completely used for bugfixing releases.

My 2 cents,
Simon

On 06/12/2018 11:17, Vincent Massol wrote:

> Hi Edy,
>
>> On 19 Nov 2018, at 19:15, Eduard Moraru <[hidden email]> wrote:
>>
>> Hi, Vincent.
>>
>> +1 for the general goal of avoiding needless holiday stress.
>>
>> Now, on the details, there is something I'm struggling to understand:
>> * I see that we have 2 options for finishing N.11:
>> A) In the middle of December (i.e. 10.11RC on 10th of Dec -2w- and 10.11
>> Final on 17 Dec -1w-), similar to what we did for 9.11.x (9.11RC1 was on
>> 11th of Dec 2017 and 9.11 Final was on 18th of Dec 2017)
>
>> B) At the beginning of January (i.e. 10.11RC on 17th of Dec -3w- and 10.11
>> Final on the 7th of Jan 2019 -3w-)
>> ** I would personally prefer A) in order to "close the books" before the
>> holiday season and start fresh in January. Anyone working during the
>> Holidays can start on N+1.0 or work on bugfixes for N.11.1.
>> * In both cases, N+1.0 should be same at the end of January, not February.
>> ** Why would it have to be end of February, and thus lose a release, as
>> mentioned in your "Cons" section?
>> ** I get it if it comes as a new proposal to double the length of N.0 to 2m
>> instead of 1 (for which I'd be +0, since I prefer less exceptions, if
>> possible), but I don't get it if we see it as a consequence of how we
>> handle holidays.
>>
>> Side note: While trying to understand how all of this works, I can't but
>> help to notice how the week-based calculations don't add up, since a month
>> is 4.3(3) weeks long and everything planned around weeks is bound to be
>> distorted when you look at it by months. IMO, it would make more sense to
>> reason in terms of months (synchronized with our 12 releases cycle) and say
>> things like "last Monday of December". Not sure how easy it would be to
>> work with... just food for thought.
>
> Some comments:
>
> 1) We already work by months, see https://www.xwiki.org/xwiki/bin/view/Roadmaps/#HXWiki10.xCycle. When we plan a given release we adjust (a bit more days or a bit less days) so that it’s released before the end of the month.
>
> 2) If I sum up your proposal A) it’s about saying that the last release would be shorter than the other ones. Say half a month vs one month (we can’t guarantee 3 weeks vs 1 month IMO since there can be delays for the previous release, people on early holidays, etc).
>
> Pros and cons of option A vs option B:
>
> * More logical, feel nice to have 12 releases for 12 months and to “fully” finish the N cycle before new year starts (in practice it’s false, see below).
> * More stressful, little margin for error and less time for the last release
> * No time at all planned for the bug fix release we need to do for the LTS. That’s the biggest issue for option A and what we saw in practice over the past years: we start the new cycle at beginning of Jan and at the same time we have to do the bug fix release for the LTS. In practice this usually means that N+1.0 has little progress in it.
>
> Note that what we did in the past was slightly different:
> * We planned for 11 releases (and not 12).
> * We said that the end of the year (last month) was 2 stabilization releases of 2 weeks each (no RCs).
>
> IMO if we want to fully finish by end of year we need to include at least one bugfix release for the LTS before the end of the year, which means stopping the dev at end of November (i.e. N.10) and then do a first bugfix release (N.10.1) for mid December and a last bugfix release (N.10.2) from Mid December to early January (2nd or 3rd of Jan).
>
> I am under the impression that option B) (the one I proposed) would be less stressful. It comes at the expense of 1 release less but I’m not sure that this would be a huge issue.
>  
> @Devs: what would you prefer?
>
> Thanks
> -Vincent
>
> PS: We need to hurry to decide if we want to put this in place in the coming days… Might be too late already for some options.
>
>
>>
>> Thanks,
>> Eduard
>>
>>
>>
>> On Mon, Nov 19, 2018 at 6:13 PM Vincent Massol <[hidden email]> 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
>>>
>>>
>

--
Simon Urli
Software Engineer at XWiki SAS
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Change of XS Cycle strategy to account for Christmas

Ecaterina Moraru (Valica)
In reply to this post by vmassol
On Thu, Dec 6, 2018 at 12:17 PM Vincent Massol <[hidden email]> wrote:

> Hi Edy,
>
> > On 19 Nov 2018, at 19:15, Eduard Moraru <[hidden email]> wrote:
> >
> > Hi, Vincent.
> >
> > +1 for the general goal of avoiding needless holiday stress.
> >
> > Now, on the details, there is something I'm struggling to understand:
> > * I see that we have 2 options for finishing N.11:
> > A) In the middle of December (i.e. 10.11RC on 10th of Dec -2w- and 10.11
> > Final on 17 Dec -1w-), similar to what we did for 9.11.x (9.11RC1 was on
> > 11th of Dec 2017 and 9.11 Final was on 18th of Dec 2017)
>
> > B) At the beginning of January (i.e. 10.11RC on 17th of Dec -3w- and
> 10.11
> > Final on the 7th of Jan 2019 -3w-)
> > ** I would personally prefer A) in order to "close the books" before the
> > holiday season and start fresh in January. Anyone working during the
> > Holidays can start on N+1.0 or work on bugfixes for N.11.1.
> > * In both cases, N+1.0 should be same at the end of January, not
> February.
> > ** Why would it have to be end of February, and thus lose a release, as
> > mentioned in your "Cons" section?
> > ** I get it if it comes as a new proposal to double the length of N.0 to
> 2m
> > instead of 1 (for which I'd be +0, since I prefer less exceptions, if
> > possible), but I don't get it if we see it as a consequence of how we
> > handle holidays.
> >
> > Side note: While trying to understand how all of this works, I can't but
> > help to notice how the week-based calculations don't add up, since a
> month
> > is 4.3(3) weeks long and everything planned around weeks is bound to be
> > distorted when you look at it by months. IMO, it would make more sense to
> > reason in terms of months (synchronized with our 12 releases cycle) and
> say
> > things like "last Monday of December". Not sure how easy it would be to
> > work with... just food for thought.
>
> Some comments:
>
> 1) We already work by months, see
> https://www.xwiki.org/xwiki/bin/view/Roadmaps/#HXWiki10.xCycle. When we
> plan a given release we adjust (a bit more days or a bit less days) so that
> it’s released before the end of the month.
>
> 2) If I sum up your proposal A) it’s about saying that the last release
> would be shorter than the other ones. Say half a month vs one month (we
> can’t guarantee 3 weeks vs 1 month IMO since there can be delays for the
> previous release, people on early holidays, etc).
>
> Pros and cons of option A vs option B:
>
> * More logical, feel nice to have 12 releases for 12 months and to “fully”
> finish the N cycle before new year starts (in practice it’s false, see
> below).
> * More stressful, little margin for error and less time for the last
> release
> * No time at all planned for the bug fix release we need to do for the
> LTS. That’s the biggest issue for option A and what we saw in practice over
> the past years: we start the new cycle at beginning of Jan and at the same
> time we have to do the bug fix release for the LTS. In practice this
> usually means that N+1.0 has little progress in it.
>
> Note that what we did in the past was slightly different:
> * We planned for 11 releases (and not 12).
> * We said that the end of the year (last month) was 2 stabilization
> releases of 2 weeks each (no RCs).
>
> IMO if we want to fully finish by end of year we need to include at least
> one bugfix release for the LTS before the end of the year, which means
> stopping the dev at end of November (i.e. N.10) and then do a first bugfix
> release (N.10.1) for mid December and a last bugfix release (N.10.2) from
> Mid December to early January (2nd or 3rd of Jan).
>

I also like this version because:
* It encapsulates a cycle only in a year span, for example 10.x would go
mainly in 2018, not spanning also in January 2019. Yes, we will still have
other bugfixes, since it becomes the LTS, but they have a secondary focus,
not a primary one.
* Releasing bugfix releases is more easy than major releases, so it might
be easier / faster and help with the holiday period.

Thanks,
Caty


>
> I am under the impression that option B) (the one I proposed) would be
> less stressful. It comes at the expense of 1 release less but I’m not sure
> that this would be a huge issue.
>
> @Devs: what would you prefer?
>
> Thanks
> -Vincent
>
> PS: We need to hurry to decide if we want to put this in place in the
> coming days… Might be too late already for some options.
>
>
> >
> > Thanks,
> > Eduard
> >
> >
> >
> > On Mon, Nov 19, 2018 at 6:13 PM Vincent Massol <[hidden email]>
> 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
> >>
> >>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Change of XS Cycle strategy to account for Christmas

Marius Dumitru Florea
In reply to this post by Simon Urli
On Thu, Dec 6, 2018 at 12:54 PM Simon Urli <[hidden email]> wrote:

> Hi all,
>
> I'm ok with the first proposal to reduce at 11 releases instead of 12.
> I think it allows indeed to better polish the latest release and avoid
> lot of stress at the end of the year.
>
> Now on the implem I'd agree more on your last mail, ie:
>
>  > stopping the dev at end of November (i.e. N.10) and then do a first
> bugfix release (N.10.1) for mid December and a last bugfix release
> (N.10.2) from Mid December to early January (2nd or 3rd of Jan).
>
> than with your first one:
>
>  > * 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
>
>

> So +1 for 11 releases, the 11th released at the end of november and then
> december is completely used for bugfixing releases.
>

+1 as well.

Thanks,
Marius


>
> My 2 cents,
> Simon
>
> On 06/12/2018 11:17, Vincent Massol wrote:
> > Hi Edy,
> >
> >> On 19 Nov 2018, at 19:15, Eduard Moraru <[hidden email]> wrote:
> >>
> >> Hi, Vincent.
> >>
> >> +1 for the general goal of avoiding needless holiday stress.
> >>
> >> Now, on the details, there is something I'm struggling to understand:
> >> * I see that we have 2 options for finishing N.11:
> >> A) In the middle of December (i.e. 10.11RC on 10th of Dec -2w- and 10.11
> >> Final on 17 Dec -1w-), similar to what we did for 9.11.x (9.11RC1 was on
> >> 11th of Dec 2017 and 9.11 Final was on 18th of Dec 2017)
> >
> >> B) At the beginning of January (i.e. 10.11RC on 17th of Dec -3w- and
> 10.11
> >> Final on the 7th of Jan 2019 -3w-)
> >> ** I would personally prefer A) in order to "close the books" before the
> >> holiday season and start fresh in January. Anyone working during the
> >> Holidays can start on N+1.0 or work on bugfixes for N.11.1.
> >> * In both cases, N+1.0 should be same at the end of January, not
> February.
> >> ** Why would it have to be end of February, and thus lose a release, as
> >> mentioned in your "Cons" section?
> >> ** I get it if it comes as a new proposal to double the length of N.0
> to 2m
> >> instead of 1 (for which I'd be +0, since I prefer less exceptions, if
> >> possible), but I don't get it if we see it as a consequence of how we
> >> handle holidays.
> >>
> >> Side note: While trying to understand how all of this works, I can't but
> >> help to notice how the week-based calculations don't add up, since a
> month
> >> is 4.3(3) weeks long and everything planned around weeks is bound to be
> >> distorted when you look at it by months. IMO, it would make more sense
> to
> >> reason in terms of months (synchronized with our 12 releases cycle) and
> say
> >> things like "last Monday of December". Not sure how easy it would be to
> >> work with... just food for thought.
> >
> > Some comments:
> >
> > 1) We already work by months, see
> https://www.xwiki.org/xwiki/bin/view/Roadmaps/#HXWiki10.xCycle. When we
> plan a given release we adjust (a bit more days or a bit less days) so that
> it’s released before the end of the month.
> >
> > 2) If I sum up your proposal A) it’s about saying that the last release
> would be shorter than the other ones. Say half a month vs one month (we
> can’t guarantee 3 weeks vs 1 month IMO since there can be delays for the
> previous release, people on early holidays, etc).
> >
> > Pros and cons of option A vs option B:
> >
> > * More logical, feel nice to have 12 releases for 12 months and to
> “fully” finish the N cycle before new year starts (in practice it’s false,
> see below).
> > * More stressful, little margin for error and less time for the last
> release
> > * No time at all planned for the bug fix release we need to do for the
> LTS. That’s the biggest issue for option A and what we saw in practice over
> the past years: we start the new cycle at beginning of Jan and at the same
> time we have to do the bug fix release for the LTS. In practice this
> usually means that N+1.0 has little progress in it.
> >
> > Note that what we did in the past was slightly different:
> > * We planned for 11 releases (and not 12).
> > * We said that the end of the year (last month) was 2 stabilization
> releases of 2 weeks each (no RCs).
> >
> > IMO if we want to fully finish by end of year we need to include at
> least one bugfix release for the LTS before the end of the year, which
> means stopping the dev at end of November (i.e. N.10) and then do a first
> bugfix release (N.10.1) for mid December and a last bugfix release (N.10.2)
> from Mid December to early January (2nd or 3rd of Jan).
> >
> > I am under the impression that option B) (the one I proposed) would be
> less stressful. It comes at the expense of 1 release less but I’m not sure
> that this would be a huge issue.
> >
> > @Devs: what would you prefer?
> >
> > Thanks
> > -Vincent
> >
> > PS: We need to hurry to decide if we want to put this in place in the
> coming days… Might be too late already for some options.
> >
> >
> >>
> >> Thanks,
> >> Eduard
> >>
> >>
> >>
> >> On Mon, Nov 19, 2018 at 6:13 PM Vincent Massol <[hidden email]>
> 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
> >>>
> >>>
> >
>
> --
> Simon Urli
> Software Engineer at XWiki SAS
> [hidden email]
> More about us at http://www.xwiki.com
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Change of XS Cycle strategy to account for Christmas

vmassol
Administrator
In reply to this post by vmassol
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.
* 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

> On 19 Nov 2018, at 17:13, Vincent Massol <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Change of XS Cycle strategy to account for Christmas

Adel Atallah
Hello,

+1 for the proposal.

Thanks,
Adel

On Sun, Dec 9, 2018 at 4:07 PM Vincent Massol <[hidden email]> 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.
> * 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
>
> > On 19 Nov 2018, at 17:13, Vincent Massol <[hidden email]> 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
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Change of XS Cycle strategy to account for Christmas

Thomas Mortagne
Administrator
In reply to this post by vmassol
+1
On Sun, Dec 9, 2018 at 4:07 PM Vincent Massol <[hidden email]> 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.
> * 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
>
> > On 19 Nov 2018, at 17:13, Vincent Massol <[hidden email]> 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
> >
>


--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Change of XS Cycle strategy to account for Christmas

Marius Dumitru Florea
In reply to this post by vmassol
+1

Thanks,
Marius

On Sun, Dec 9, 2018 at 5:07 PM Vincent Massol <[hidden email]> 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.
> * 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
>
> > On 19 Nov 2018, at 17:13, Vincent Massol <[hidden email]> 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
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Change of XS Cycle strategy to account for Christmas

Ecaterina Moraru (Valica)
+1

Thanks,
Caty

On Mon, Dec 10, 2018 at 12:36 PM Marius Dumitru Florea <
[hidden email]> wrote:

> +1
>
> Thanks,
> Marius
>
> On Sun, Dec 9, 2018 at 5:07 PM Vincent Massol <[hidden email]> 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.
> > * 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
> >
> > > On 19 Nov 2018, at 17:13, Vincent Massol <[hidden email]> 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
> > >
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Change of XS Cycle strategy to account for Christmas

Eduard Moraru
In reply to this post by vmassol
Hi,

On Sun, Dec 9, 2018 at 5:07 PM Vincent Massol <[hidden email]> 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).


> * 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 <[hidden email]> 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
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Change of XS Cycle strategy to account for Christmas

vmassol
Administrator


> On 10 Dec 2018, at 12:14, Eduard Moraru <[hidden email]> wrote:
>
> Hi,
>
> On Sun, Dec 9, 2018 at 5:07 PM Vincent Massol <[hidden email]> 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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Change of XS Cycle strategy to account for Christmas

vmassol
Administrator
In reply to this post by vmassol
Hi devs,

> On 9 Dec 2018, at 16:07, Vincent Massol <[hidden email]> 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.
> * 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

I have now recreated the releasecycle image, see
https://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractices#Attachments

So now we need to remember that this year we’ll go till 11.10, then 11.10.1 and 11.10.2 at end of year 2019.

Thanks
-Vincent

>
> Thanks
> -Vincent
>
>> On 19 Nov 2018, at 17:13, Vincent Massol <[hidden email]> 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
>>
>