You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mapreduce-dev@hadoop.apache.org by Karthik Kambatla <ka...@cloudera.com> on 2016/08/12 23:45:50 UTC
[DISCUSS] Release cadence and EOL
Forking off this discussion from 2.6.5 release thread. Junping and Chris T
have brought up important concerns regarding too many concurrent releases
and the lack of EOL for our releases.
First up, it would be nice to hear from others on our releases having the
notion of EOL and other predictability is indeed of interest.
Secondly, I believe EOLs work better in conjunction with a predictable
cadence. Given past discussions on this and current periods between our
minor releases, I would like to propose a minor release on the latest major
line every 6 months and a maintenance release on the latest minor release
every 2 months.
Eager to hear others thoughts.
Thanks
Karthik
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.
> > >
> > >
> > >
> >
>
Re: [DISCUSS] Release cadence and EOL
Posted by Andrew Wang <an...@cloudera.com>.
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>.
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>.
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>.
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>.
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>.
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>.
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>.
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>.
>
>
> 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>.
>
>
> 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>.
>
>
> 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>.
>
>
> 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 Karthik for opening a long overdue discussion on the release cadence
and EOL.
As for the EOL, I think we need to weigh between the benefit for the users
and the maintenance cost for the community. I'd also love to find out what
other (major) open source projects do in terms of the EOL.
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."
The idea is to cap the maintenance at 2 years first, but also to consider
the actual alternatives. If there were 2 more minor releases, I think they
should be good alternatives for users to upgrade. That would also cap the
number of simultaneous maintenance lines at 2. I purposefully didn't
include major releases (e.g. 3.0.0) in this as it would take a much longer
time for users to upgrade from a previous major release.
Finally, I think it'd be good to have an escape clause for this so that the
community can make a collective decision to extend certain release lines if
it is deemed better for the community.
This is just a starting point for discussion. Thoughts?
Thanks,
Sangjin
On Fri, Aug 12, 2016 at 4:45 PM, Karthik Kambatla <ka...@cloudera.com>
wrote:
> Forking off this discussion from 2.6.5 release thread. Junping and Chris T
> have brought up important concerns regarding too many concurrent releases
> and the lack of EOL for our releases.
>
> First up, it would be nice to hear from others on our releases having the
> notion of EOL and other predictability is indeed of interest.
>
> Secondly, I believe EOLs work better in conjunction with a predictable
> cadence. Given past discussions on this and current periods between our
> minor releases, I would like to propose a minor release on the latest major
> line every 6 months and a maintenance release on the latest minor release
> every 2 months.
>
> Eager to hear others thoughts.
>
> Thanks
> Karthik
>
Re: [DISCUSS] Release cadence and EOL
Posted by Sangjin Lee <sj...@apache.org>.
Thanks Karthik for opening a long overdue discussion on the release cadence
and EOL.
As for the EOL, I think we need to weigh between the benefit for the users
and the maintenance cost for the community. I'd also love to find out what
other (major) open source projects do in terms of the EOL.
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."
The idea is to cap the maintenance at 2 years first, but also to consider
the actual alternatives. If there were 2 more minor releases, I think they
should be good alternatives for users to upgrade. That would also cap the
number of simultaneous maintenance lines at 2. I purposefully didn't
include major releases (e.g. 3.0.0) in this as it would take a much longer
time for users to upgrade from a previous major release.
Finally, I think it'd be good to have an escape clause for this so that the
community can make a collective decision to extend certain release lines if
it is deemed better for the community.
This is just a starting point for discussion. Thoughts?
Thanks,
Sangjin
On Fri, Aug 12, 2016 at 4:45 PM, Karthik Kambatla <ka...@cloudera.com>
wrote:
> Forking off this discussion from 2.6.5 release thread. Junping and Chris T
> have brought up important concerns regarding too many concurrent releases
> and the lack of EOL for our releases.
>
> First up, it would be nice to hear from others on our releases having the
> notion of EOL and other predictability is indeed of interest.
>
> Secondly, I believe EOLs work better in conjunction with a predictable
> cadence. Given past discussions on this and current periods between our
> minor releases, I would like to propose a minor release on the latest major
> line every 6 months and a maintenance release on the latest minor release
> every 2 months.
>
> Eager to hear others thoughts.
>
> Thanks
> Karthik
>
Re: [DISCUSS] Release cadence and EOL
Posted by Sangjin Lee <sj...@apache.org>.
Thanks Karthik for opening a long overdue discussion on the release cadence
and EOL.
As for the EOL, I think we need to weigh between the benefit for the users
and the maintenance cost for the community. I'd also love to find out what
other (major) open source projects do in terms of the EOL.
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."
The idea is to cap the maintenance at 2 years first, but also to consider
the actual alternatives. If there were 2 more minor releases, I think they
should be good alternatives for users to upgrade. That would also cap the
number of simultaneous maintenance lines at 2. I purposefully didn't
include major releases (e.g. 3.0.0) in this as it would take a much longer
time for users to upgrade from a previous major release.
Finally, I think it'd be good to have an escape clause for this so that the
community can make a collective decision to extend certain release lines if
it is deemed better for the community.
This is just a starting point for discussion. Thoughts?
Thanks,
Sangjin
On Fri, Aug 12, 2016 at 4:45 PM, Karthik Kambatla <ka...@cloudera.com>
wrote:
> Forking off this discussion from 2.6.5 release thread. Junping and Chris T
> have brought up important concerns regarding too many concurrent releases
> and the lack of EOL for our releases.
>
> First up, it would be nice to hear from others on our releases having the
> notion of EOL and other predictability is indeed of interest.
>
> Secondly, I believe EOLs work better in conjunction with a predictable
> cadence. Given past discussions on this and current periods between our
> minor releases, I would like to propose a minor release on the latest major
> line every 6 months and a maintenance release on the latest minor release
> every 2 months.
>
> Eager to hear others thoughts.
>
> Thanks
> Karthik
>
Re: [DISCUSS] Release cadence and EOL
Posted by Sangjin Lee <sj...@apache.org>.
Thanks Karthik for opening a long overdue discussion on the release cadence
and EOL.
As for the EOL, I think we need to weigh between the benefit for the users
and the maintenance cost for the community. I'd also love to find out what
other (major) open source projects do in terms of the EOL.
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."
The idea is to cap the maintenance at 2 years first, but also to consider
the actual alternatives. If there were 2 more minor releases, I think they
should be good alternatives for users to upgrade. That would also cap the
number of simultaneous maintenance lines at 2. I purposefully didn't
include major releases (e.g. 3.0.0) in this as it would take a much longer
time for users to upgrade from a previous major release.
Finally, I think it'd be good to have an escape clause for this so that the
community can make a collective decision to extend certain release lines if
it is deemed better for the community.
This is just a starting point for discussion. Thoughts?
Thanks,
Sangjin
On Fri, Aug 12, 2016 at 4:45 PM, Karthik Kambatla <ka...@cloudera.com>
wrote:
> Forking off this discussion from 2.6.5 release thread. Junping and Chris T
> have brought up important concerns regarding too many concurrent releases
> and the lack of EOL for our releases.
>
> First up, it would be nice to hear from others on our releases having the
> notion of EOL and other predictability is indeed of interest.
>
> Secondly, I believe EOLs work better in conjunction with a predictable
> cadence. Given past discussions on this and current periods between our
> minor releases, I would like to propose a minor release on the latest major
> line every 6 months and a maintenance release on the latest minor release
> every 2 months.
>
> Eager to hear others thoughts.
>
> Thanks
> Karthik
>