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