I am certainly in favor of doing a vote for the same. Along with that, we should likely make some progress on the logistic issues with doing a release that Andrew raised.
On Tue, Jan 3, 2017 at 4:06 PM, Sangjin Lee <sj...@apache.org> wrote: > Happy new year! > > I think this topic has aged quite a bit in the discussion thread. Should > we take it to a vote? Do we need additional discussions? > > Regards, > Sangjin > > On Wed, Nov 9, 2016 at 11:11 PM, Karthik Kambatla <ka...@cloudera.com> > wrote: > >> Fair points, Sangjin and Andrew. >> >> To get the ball rolling on this, I am willing to try the proposed policy. >> >> On Fri, Nov 4, 2016 at 12:09 PM, Andrew Wang <andrew.w...@cloudera.com> >> wrote: >> >> > I'm certainly willing to try this policy. There's definitely room for >> > improvement when it comes to streamlining the release process. The >> > create-release script that Allen wrote helps, but there are still a lot >> of >> > manual steps in HowToRelease for staging and publishing a release. >> > >> > Another perennial problem is reconciling git log with the changes and >> > release notes and JIRA information. I think each RM has written their >> own >> > scripts for this, but it could probably be automated into a Jenkins >> report. >> > >> > And the final problem is that branches are often not in a releasable >> > state. This is because we don't have any upstream integration testing. >> For >> > instance, testing with 3.0.0-alpha1 has found a number of latent >> > incompatibilities in the 2.8.0 branch. If we want to meaningfully speed >> up >> > the minor release cycle, continuous integration testing is a must. >> > >> > Best, >> > Andrew >> > >> > On Fri, Nov 4, 2016 at 10:33 AM, Sangjin Lee <sj...@apache.org> wrote: >> > >> >> 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. >> >>> > > >> >>> > > >> >>> > > >> >>> > >> >>> >> >> >> >> >> > >> > >
