6 Dec
2018
6 Dec
'18
11:57 a.m.
On Thu, Dec 6, 2018 at 12:17 PM Vincent Massol <vincent(a)massol.net> wrote:
Hi Edy,
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
On 19 Nov 2018, at 19:15, Eduard Moraru
<enygma2002(a)gmail.com> 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 <vincent(a)massol.net>
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
>
>