As the project matures, I expect at least part of major release line lifetime will be driven by adoption since we're volunteer driven.
For example, HBase 0.94 (a major release line) has outlived HBase 0.96 and may outlive 0.98 yet (both major release lines). Part of this was because the community failed to provide a zero-downtime option for upgrading off of 0.94, but some of it is just a matter of timing and upgrade cycles in large IT shops. Development on the line has progressively slowed; it got new features for some time, but has been locked into critical bug fixes for about a year now. Part of the reason HBase has been able to use an adaptive lifetime for release lines is that we get a volunteer to sign up as Release Manager (originally over a major release's life and lately over a minor). That RM then did the majority of work monitoring the activity of a branch line. As incoming patches slow down they take the lead in 1) ensuring that critical patches devs forget to backport still show up before release, and 2) driving community expectations around the branch (e.g. "I'm planning to slow the release cycle to quarterly, so anyone think that'll adversely impact them too much?"). Full disclosure, HBase hasn't worked out changes to major release lifecycle since it transitioned to have patch releases (post 1.0.0) back in February; for now we just wait for activity to slow on minor releases like we did for the older major releases. On Tue, Sep 29, 2015 at 9:31 AM, Joe Witt <joe.w...@gmail.com> wrote: > Team, > > We should discuss an important topic that Sean Busbey raised which is > what is our plan to support major release lines. > > We should identify: > - how long to support the previous major release line(s) > - what type of support we'd provide (feature porting, bugs only, > critical bugs only, critical security bugs only) > > I would like to propose that we only offer critical security bug fixes > to old release lines as a general philosophy. But I am certainly ears > open to understanding a broader view from users or those more > experienced managing these sorts of projects. > > Look forward to seeing some thoughtful perspectives and inputs. > > Thanks > Joe -- Sean
