Hello,
I would like to start a discussion about our time-based release
schedule. We have a discussion (that I personally find a little bit
annoying and tedious) about release plan dates on every single release
(the 4.4.0 discussion, is just another example). And we still often end
up with none-optimal time-frames (4.4 might also be an example here --
not by itself, but the impact on 4.5 release timeline -- cf my latest
reply on the other thread).
Given that we actually plan to have time-based releases, I think we
should agree on a more fixed schedule, which allows us to project all
release dates (including KIP/feature/code freeze) into the future and
just be done with it. -- And even if we need an exception from the rule,
we can easily get back on track on future release afterwards.
I was also looking into historic data, and while we overall don't do too
bad to stay on track for 3 release per year, we had to pay the price of
a few short release cycles to "shift back" (the previous 4.3 release is
a good example of it), while we still did shift somewhat forward
overall. These short releases cause even more pain IMHO.
To avoid problems with the holiday season end of the year, I would like
to propose the following fixed release cadence (this is not my personal
favorite, but let's start here):
1. KIP freeze is the second Wednesday of January, May, and September.
2. Feature freeze = KIP freeze + 3 weeks.
3. Code freeze = Feature freeze + 3 weeks.
4. Release target = Code freeze + 4 weeks.
While we never officially formalized the 3+3 weeks between KIP/feature
and feature/code freeze dates (and we used shorter time windows in the
past, ie, 2+2 weeks), 3+3 established itself since 4.0 release -- I am
totally open for other time frames, but believe we should not go shorter
than 2+2 weeks. I would also not make them longer than 3+3, as it would
just give us the subjective impression that releases are closer to each
other.
A 3+2 schedule would actually be my personal preference. For KIPs,
giving only 2 weeks to complete them is tight, even for simple KIPs. And
for bug-fixes, I would believe that 2 weeks are enough. Making it
overall 5 week instead of 6, also helps to keep releases 1 week "further
apart" from each other (not really, but we know how reality works, given
our subjective nature).
The above schedule implies that we would have target release dates late
March, July, and November. Even if we need more than 4 weeks after code
freeze, we still have some head room in the November release before the
holidays (we might hit Thanksgiving, but I think that's ok). For the KIP
freeze in January, it should also give enough time after the holidays to
complete KIPs and get them accepted (w/o being too close to the
holidays, eg, "first Wednesday in January" would effectively mean, that
KIPs must get voted before the holiday break).
If we want to take the holiday season into account even more, we could
also make the timeline between "release 3" and "release 1 of the
following year" two weeks longer, and the other two timelines 1 week
shorter. This would give us the following KIP freeze deadlines:
- third Wednesday of January
- second Wednesday of May
- first Wednesday of September
It also implies, that Thanksgiving would be less of an issue for
"release 3". This schedule is what I would personally prefer, instead of
an 100% equal distribution of our 52 weeks across all three releases.
For the upcoming 4.4 release, we should make it a 5-month cycle
targeting October instead of September, and we would also have a
slightly longer cycle for 4.6, which we should only start in January.
However, starting with 4.6 we would enter the above proposed fixed
timeline, putting us into a much better position going forward IMHO.
Looking forward to your thoughts on this idea.
-Matthias
