Assuming major upgrades will sometimes break compatibility, I think we need to plan on providing general bug fixes, not just security or critical fixes, to at least the last major release. I like the idea of those patch releases becoming less frequent as the age of the release increases. I don't think we should prioritize new features for older major releases, but I could imagine there will be times when it's required like in situations like HBase 0.94 that Sean mentioned.
For releases older than N-1, I'd think only critical bugs and security fixes are needed. Assuming we get a good cadence of major releases, I think that dropping support for anything older than N-2 or N-3 would also make sense. -Joey On Tue, Sep 29, 2015 at 11:19 AM, Sean Busbey <[email protected]> wrote: > 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 <[email protected]> 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 >
