hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karthik Kambatla <ka...@cloudera.com>
Subject Re: [DISCUSS] Release cadence and EOL
Date Thu, 10 Nov 2016 07:11:29 GMT
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.wang@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 <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