Thanks for your thoughts and more data points Andrew. I share your concern that the proposal may be more aggressive than what we have been able to accomplish so far. I'd like to hear from the community what is a desirable release cadence which is still within the realm of the possible.
The EOL policy can also be a bit of a forcing function. By having a defined EOL, hopefully it would prod the community to move faster with releases. Of course, automating releases and testing should help. On Tue, Nov 1, 2016 at 4:31 PM, Andrew Wang <andrew.w...@cloudera.com> wrote: > 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. > > > > > > > > > > > >
