Thanks for pushing on this Sangjin. The proposal sounds reasonable. However, for it to have teeth, we need to be *very* disciplined about the release cadence. Looking at our release history, we've done 4 maintenance releases in 2016 and no minor releases. 2015 had 4 maintenance and 1 minor release. The proposal advocates for 12 maintenance releases and 2 minors per year, or about 3.5x more releases than we've historically done. I think achieving this will require significantly streamlining our release and testing process.
For some data points, here are a few EOL lifecycles for some major projects. They talk about support in terms of time (not number of releases), and release on a cadence. Ubuntu maintains LTS for 5 years: https://www.ubuntu.com/info/release-end-of-life Linux LTS kernels have EOLs ranging from 2 to 6 years, though it seems only one has actually ever been EOL'd: https://www.kernel.org/category/releases.html Mesos supports minor releases for 6 months, with a new minor every 2 months: http://mesos.apache.org/documentation/latest/versioning/ Eclipse maintains each minor for ~9 months before moving onto a new minor: http://stackoverflow.com/questions/35997352/how-to-determine-end-of-life-for-eclipse-versions On Fri, Oct 28, 2016 at 10:55 AM, Sangjin Lee <sj...@apache.org> wrote: > Reviving an old thread. I think we had a fairly concrete proposal on the > table that we can vote for. > > The proposal is a minor release on the latest major line every 6 months, > and a maintenance release on a minor release (as there may be concurrently > maintained minor releases) every 2 months. > > A minor release line is EOLed 2 years after it is first released or there > are 2 newer minor releases, whichever is sooner. The community reserves the > right to extend or shorten the life of a release line if there is a good > reason to do so. > > Comments? Objections? > > Regards, > Sangjin > > > On Tue, Aug 23, 2016 at 9:33 AM, Karthik Kambatla <ka...@cloudera.com> > wrote: > > > > >> Here is just an idea to get started. How about "a minor release line is > >> EOLed 2 years after it is released or there are 2 newer minor releases, > >> whichever is sooner. The community reserves the right to extend or > shorten > >> the life of a release line if there is a good reason to do so." > >> > >> > > Sounds reasonable, especially for our first commitment. For current > > releases, this essentially means 2.6.x is maintained until Nov 2016 and > Apr > > 2017 if 2.8 and 2.9 are not released by those dates. > > > > IIUC EOL does two things - (1) eases the maintenance cost for developers > > past EOL, and (2) indicates to the user when they must upgrade by. For > the > > latter, would users appreciate a specific timeline without any caveats > for > > number of subsequent minor releases? > > > > If we were to give folks a specific period for EOL for x.y.z, we should > > plan on releasing at least x.y+1.1 by then. 2 years might be a good > number > > to start with given our current cadence, and adjusted in the future as > > needed. > > > > > > >
