Totally agree with all the frustrations felt by Jon here.

TL;DR
Here's a proposal for 4.0 and beyond: that is puts together the comments
from Benedict, Jon, Tyler, Jeremy, and Ed;

 - keep bimonthly feature releases,
 - revert from tick-tock to SemVer numbering scheme,
 - during the release vote also vote on the quality label (feature branches
start with a 'Alpha' and the first patch release as 'Beta'),
 - accept that every feature release isn't by default initially supported,
and its branch might never be,
 - maintain 3 'GA' branches at any one time,
 - accept that it's not going to be the oldest GA branches that necessarily
reach EOL first.


Background and rationale…

IMO the problem with Tick-Tock is that it introduces two separate concepts:
       - incremental development, and
       - limiting patch releases.

The first concept: having bimonthly tocks; made C* development more
incremental. A needed improvement.
No coincidence, at the same time as tick-tock was introduced, there was
also a lot of effort being put into testing and a QA framework.
>From this we've seen a lot of fantastic features incrementally added to C*!

The second concept: having bimonthly ticks; limited C* to having only one
patch release per tock release.
The only real benefit to this was to reduce the effort involved in
maintenance, required because of the more frequent tock releases.
The consequence is instability has gone bananas, as Jon clearly
demonstrates. Someone went and let the monkey out.

A quick comparison of before to tick-tock:

   * Before tick-tock: against 6-12 months of development it took a
time-frame of 3-6 months and 6+ patch releases to stabilise C*.

   * After tick-tock: against 2 months of development we could have
expected the same time-frame of 3-6 months (because adoption is dictated by
users, not developers) and *over* this period 1-2 patch releases to
stabilise. It seemed to have been a fools errand to force this to 1 patch
release after only one month. It seems that the notion of incremental
development was applied for the developers where-as the waterfall model was
applied to QA in production for the users. (note: all this is not taking
into account advantages of incremental development, an improved QA
framework, and a move towards a stable-master.)

The question remains to how many of these releases can the community afford
to support. And being realistic much of this effort relies upon the
commercial entities around the community. For example having 1 year of
support means having to support 6 feature releases, and there's probably
not the people power to do that. It also means that in effect any release
is actually only supported for 6-9 months, since it took 3-6 for it to get
to production-ready.

A typical Apache release process is that each new major release gets voted
on as only 'Alpha' or 'Beta'. As patch releases are made it is ascertained
whether enough people are using it (eg in production) and the quality label
appropriately raised to either 'Beta' or 'GA'.  The quality label can be
proposed in the vote or left to be voted upon by everyone. The quality
label is itself not part of the version number, so that the version number
can follow strict SemVer.

Then the community can say, for example, it supports 3 'GA' branches. This
permits some major releases to never make it to GA, and others to hang over
for a bit longer. It's something that the community gets a feel for by
appreciating the users and actors around it. The number of branches
supported depends on what the community can sustain (including the new
non-GA branches). The community also becomes a bit more honest about the
quality of x.y.0 releases.

The proposal is an example that embraces incremental development and the
release-often mentality, while keeping a realistic and flexible approach to
how many branches can be supported. The cost of supporting branches is
still very real, and pushing for a stable master means no feature branch is
cut without passing everything in the QA framework and 100% belief that it
can be put into a user's production. That is there's not a return to
thinking about feature branches as a place for ongoing stabilisation
efforts, just because they have a 'Alpha/Beta' label. The onus of work is
put upon the developer having to maintain branches for features targeted
for master, and not on the community having to stabilise and support
feature branches.

BTW has anyone figured out whether it's the tick or the tock that
represents the feature release??   I probably got it wrong here :-)


~mck

Reply via email to