hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sangjin Lee <sj...@apache.org>
Subject Re: [DISCUSS] Release cadence and EOL
Date Wed, 04 Jan 2017 00:06:41 GMT
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 <kasha@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.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