Re: [DISCUSS] Release cadence and EOL

[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

[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

[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

[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.
>> >>> > >
>> >>> > >
>> >>> > >
>> >>> >
>> >>>
>> >>
>> >>
>> >
>>
>
>