hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Wang <andrew.w...@cloudera.com>
Subject Re: [DISCUSS] Release cadence and EOL
Date Fri, 04 Nov 2016 19:09:31 GMT
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 <sjlee@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.wang@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 <sjlee@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 <kasha@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.
>> > >
>> > >
>> > >
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message