Re: [DISCUSS] Release cadence and EOL
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 Leewrote: > 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 > 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 >> 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 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 >> >> 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 >> 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
Re: [DISCUSS] Release cadence and EOL
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 Kambatlawrote: > 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 > 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 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 > >> 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 > 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
Re: [DISCUSS] Release cadence and EOL
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 Wangwrote: > 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 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 >> 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 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 >>> > 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
Re: [DISCUSS] Release cadence and EOL
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 Leewrote: > 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 > 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 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 >> > 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
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 Wangwrote: > 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 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 > > 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
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 Leewrote: > 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 > 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
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 Kambatlawrote: > >> 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
> > > 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
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 Kambatlawrote: > 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 >