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