Re: [Xen-devel] Xen release cycle revisited

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 19.12.17 at 07:58, <jgross@xxxxxxxx> wrote:
> My proposal addresses the 4.10 experience. I see the following
> alternatives (assuming we want to keep the two releases per year
> scheme):
> 
> 1. Leave everything as is
>    Pro: seems to work for the June release
>    Con: release date for the December release is risky
> 
> 2. Move releases one month earlier, freeze dates as well (my proposal)
>    Pro: more time for release at end of the year
>    Con: freeze date end of February at end of Chinese New Year holidays
>         in some years (2018 not applicable, as we would move that
>         release by 2 weeks only, so next time this will really hit us
>         will be 2026, maybe a little bit in 2021)
> 
> 3. Move releases one month earlier, freeze dates before holidays
>    Pro: developers won't have to let feature slip due to holiday
>    Con: shorter development time for _all_ developers
> 
> 4. Keep the June release like today, move the December release 2 or 4
>    weeks earlier
>    Pro: all Pros of 1-3
>    Con: every second release will have shorter development cycle

5. Go to a yearly release cycle, with June as expected release date.
At the risk of (still) being the only one to dislike the 6-month cycle,
I have to say that there, at the moment, being 4 actively maintained
stable branches and 6 security maintained ones is - just like I did
anticipate back when we discussed the shortening of the cycle - a
significant burden. And we haven't even reached the point yet
where all security maintained branches are from the 6-month cycle.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel