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. > >>> > > > >>> > > > >>> > > > >>> > > >>> > >> > >> > > >
