Release Cycle Observations
Donny Davis wrote:
> So when you say largely ignored, do you mean by downstream vendors who
> package Openstack or by public clouds who use it daily?
> I can see a longer release cycle being better for vendors so they don't
> have to do FFU to begin with and public clouds wanting faster releases
> so they can get features to customers sooner.
The release cycle length discussion has happened roughly every 8 months
for the last 9 years, and I don't think the reality has changed.
Longer release cycles does not facilitate merging features, nor does it
spread the load. Evidence would rather point to the opposite
(twice-bigger crunch at the end of the larger cycle).
Release cycle length actually affects three things.
1- with longer cycles, boilerplate tasks around releasing happen less
often. This is largely a non-issue now that most of the release process
2- with longer cycles, the feedback loop between when a feature is
written and when it's actually in use by users is getting longer. This
is bad as the person who writes the feature in the first place may have
moved to other things by the time the initial user feedback comes.
3- with longer cycles, there is less pressure on downstream to integrate
the new release in their products. This remains true, even if we now
have multiple options to skip irrelevant releases in products.
The current 6-month cycle is a trade-off, essentially a balance between
(2) and (3). It is as long as we think we can stretch the cycle duration
without ruining the feedback loop.
Obviously nobody is happy with it, with some wanting it to be longer,
and some wanting it to be shorter. Which means that it is probably a
good middle ground :)
Thierry Carrez (ttx)