You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-dev@hadoop.apache.org by Andrew Wang <an...@cloudera.com> on 2016/11/01 23:31:51 UTC
Re: [DISCUSS] Release cadence and EOL
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.
> >
> >
> >
>
Re: [DISCUSS] Release cadence and EOL
Posted by Karthik Kambatla <ka...@cloudera.com>.
I am certainly in favor of doing a vote for the same.
Along with that, we should likely make some progress on the logistic issues
with doing a release that Andrew raised.
On Tue, Jan 3, 2017 at 4:06 PM, Sangjin Lee <sj...@apache.org> wrote:
> 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 <ka...@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 <an...@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 <an...@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 <
>> 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.
>> >>> > >
>> >>> > >
>> >>> > >
>> >>> >
>> >>>
>> >>
>> >>
>> >
>>
>
>
Re: [DISCUSS] Release cadence and EOL
Posted by Karthik Kambatla <ka...@cloudera.com>.
I am certainly in favor of doing a vote for the same.
Along with that, we should likely make some progress on the logistic issues
with doing a release that Andrew raised.
On Tue, Jan 3, 2017 at 4:06 PM, Sangjin Lee <sj...@apache.org> wrote:
> 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 <ka...@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 <an...@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 <an...@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 <
>> 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.
>> >>> > >
>> >>> > >
>> >>> > >
>> >>> >
>> >>>
>> >>
>> >>
>> >
>>
>
>
Re: [DISCUSS] Release cadence and EOL
Posted by Karthik Kambatla <ka...@cloudera.com>.
I am certainly in favor of doing a vote for the same.
Along with that, we should likely make some progress on the logistic issues
with doing a release that Andrew raised.
On Tue, Jan 3, 2017 at 4:06 PM, Sangjin Lee <sj...@apache.org> wrote:
> 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 <ka...@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 <an...@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 <an...@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 <
>> 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.
>> >>> > >
>> >>> > >
>> >>> > >
>> >>> >
>> >>>
>> >>
>> >>
>> >
>>
>
>
Re: [DISCUSS] Release cadence and EOL
Posted by Sangjin Lee <sj...@apache.org>.
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 <ka...@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 <an...@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 <an...@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 <
> 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.
> >>> > >
> >>> > >
> >>> > >
> >>> >
> >>>
> >>
> >>
> >
>
Re: [DISCUSS] Release cadence and EOL
Posted by Sangjin Lee <sj...@apache.org>.
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 <ka...@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 <an...@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 <an...@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 <
> 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.
> >>> > >
> >>> > >
> >>> > >
> >>> >
> >>>
> >>
> >>
> >
>
Re: [DISCUSS] Release cadence and EOL
Posted by Sangjin Lee <sj...@apache.org>.
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 <ka...@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 <an...@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 <an...@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 <
> 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.
> >>> > >
> >>> > >
> >>> > >
> >>> >
> >>>
> >>
> >>
> >
>
Re: [DISCUSS] Release cadence and EOL
Posted by Sangjin Lee <sj...@apache.org>.
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 <ka...@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 <an...@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 <an...@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 <
> 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.
> >>> > >
> >>> > >
> >>> > >
> >>> >
> >>>
> >>
> >>
> >
>
Re: [DISCUSS] Release cadence and EOL
Posted by Karthik Kambatla <ka...@cloudera.com>.
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 <an...@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 <an...@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.
>>> > >
>>> > >
>>> > >
>>> >
>>>
>>
>>
>
Re: [DISCUSS] Release cadence and EOL
Posted by Karthik Kambatla <ka...@cloudera.com>.
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 <an...@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 <an...@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.
>>> > >
>>> > >
>>> > >
>>> >
>>>
>>
>>
>
Re: [DISCUSS] Release cadence and EOL
Posted by Karthik Kambatla <ka...@cloudera.com>.
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 <an...@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 <an...@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.
>>> > >
>>> > >
>>> > >
>>> >
>>>
>>
>>
>
Re: [DISCUSS] Release cadence and EOL
Posted by Karthik Kambatla <ka...@cloudera.com>.
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 <an...@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 <an...@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.
>>> > >
>>> > >
>>> > >
>>> >
>>>
>>
>>
>
Re: [DISCUSS] Release cadence and EOL
Posted by Andrew Wang <an...@cloudera.com>.
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 <an...@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.
>> > >
>> > >
>> > >
>> >
>>
>
>
Re: [DISCUSS] Release cadence and EOL
Posted by Andrew Wang <an...@cloudera.com>.
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 <an...@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.
>> > >
>> > >
>> > >
>> >
>>
>
>
Re: [DISCUSS] Release cadence and EOL
Posted by Andrew Wang <an...@cloudera.com>.
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 <an...@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.
>> > >
>> > >
>> > >
>> >
>>
>
>
Re: [DISCUSS] Release cadence and EOL
Posted by Andrew Wang <an...@cloudera.com>.
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 <an...@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.
>> > >
>> > >
>> > >
>> >
>>
>
>
Re: [DISCUSS] Release cadence and EOL
Posted by Sangjin Lee <sj...@apache.org>.
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 <an...@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.
> > >
> > >
> > >
> >
>
Re: [DISCUSS] Release cadence and EOL
Posted by Sangjin Lee <sj...@apache.org>.
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 <an...@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.
> > >
> > >
> > >
> >
>
Re: [DISCUSS] Release cadence and EOL
Posted by Sangjin Lee <sj...@apache.org>.
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 <an...@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.
> > >
> > >
> > >
> >
>
Re: [DISCUSS] Release cadence and EOL
Posted by Sangjin Lee <sj...@apache.org>.
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 <an...@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.
> > >
> > >
> > >
> >
>