[Xen-devel] RFC: change to 6 months release cycle

[Wei Liu <wei.liu2@xxxxxxxxxx>]

Hi all

As I understand it in the past there were discussions on release every
6 months. I would like to revisit this topic.

# Rationale for a shorter release cycle

The current 9 months cadence is too long. That create at least two
problems for us.

The first problem is that Xen delivers features much slower than other
projects. Linux kernel releases every 3 months. QEMU releases every 4
months. They deliver new features at a much higher frequency.

The second problem is that the opportunity cost for vendors to miss a
release is very high. When combined with the freeze exception scheme,
tension quickly builds up around cut-off point, which creates
frictions and frustrations for both contributors and maintainers. This
is detrimental to the project in the long run.

Having a shorter release cycle plus some other measures seem to make
sense.

The main objection from previous discussion seems to be that "shorter
release cycle creates burdens for downstream projects". I couldn't
quite get the idea, but I think we can figure out a way to sort that
out once we know what exactly the burdens are.

A side note is that if we really go down this route we need to stick
with it for a few releases to let people get used to it. Any change to
the release process is going to cause some issues.

# Proposed release cycle

Aim for 6 months release cycle -- 4 months development period, 2
months hardening period. Make two releases per year.

Fixed hard cut-off date, no more freeze exception. Arrange RCs
immediately after cut-off.

Take into account holiday seasons in US, Europe and China, the two
cut-off dates are the Fridays in which that last day of March and
September are in.

Targeted release date is two months after cut-off date. Still, we pick
a Friday using the same rule. We can also release a bit earlier if
everything goes well. If we somehow fail to release on time, we eat
into next development cycle. The next cut-off date will still be
fixed.

With the proposed scheme, the dates will be:

 - 4.7 cut-off date: April 1, 2016
 - 4.7 release date: June 1, 2016

 - 4.8 cut-off date: September 30, 2016
 - 4.8 release date: December 2, 2016

 - 4.9 cut-off date: March 31, 2017
 - 4.9 release date: June 2, 2017

and it goes on.

# Feasibility analysis

Xen 4.6 is almost out of the door. I think it's convenient to use it as one
data point about how we can achieve the proposed plan.

Xen 4.6 release time line broken down:

 - developemnt: 6 months
 - consideration for freeze exception: 1 week
 - applying patches with free exception: 1 week
 - fix major bugs: 2 weeks
 - RCs: every 1 to 2 weeks

We aimed for a 9 months release cycle. That means we have 3 months for
stabilisation and RCs.

Note that the 2 weeks used to fix bugs were mostly for bugs introduced
during free exception.

The riddance of freeze exception saves us at least the first 2 weeks.
And because there are less changes due to shorter development cycle and
no freeze exception, there are probably less bugs, which means we can
potentially save another week or two. So the 6 months time line is
realistic to achieve.

We branched and reopened xen-unstable at RC3 on September 9, which is
more or less two months after freeze (July 10) and one month before
anticipated release date (October 9).  With the new release cycle, we
can probably reopen the tree after 4 to 6 weeks of frozen state. This
helps our contributors upstream their code faster.

Comments are welcome!

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel