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