This was discussed in the following thread: "[DISCUSS] Simplify active release branches (Was: Re: [DISCUSS] Git workflow)"
— http://markmail.org/message/5edirnhli43g7lt6 At the start of this thread, I put forward my rationale for dropping support for 1.2.x (namely, that 1.3.x should be forwards compatible with 1.2.x), and nobody objected. I've also made an adjustment to the "n + n-1" concept, more inline with both the Dublin discussion and the points about semver that Dale brought up, and I added it to the wiki, as previously noted in this thread. We will support each major version for 12 months. So, if 1.0.0 was released > on 2010-01-01, then we would add features and fixes to it until 2011-01-01. > After 12 months have passed, we may continue to release fixes for critical > security issues, but these will be in the form of actual patches. Note that the upgrade path for minor versions is to update the latest minor > version. We will not continue to release patch versions for an old minor > version. That is, 1.1.0 immediately supersedes 1.0.x, and no more fixes > will be made on the 1.0.x line. Similarly, 1.2.0 immediately supersedes > 1.1.x. — http://wiki.apache.org/couchdb/CurrentReleases I appreciate that this is the first time we've done this, so it might be a little surprising to people. (Though, I believe, this has been the plan for a good 12 months.) Let's closely monitor the situation, and if any issues crop up, we deal with them. On 21 May 2013 10:31, Jan Lehnardt <[email protected]> wrote: > > On May 21, 2013, at 08:32 , Benoit Chesneau <[email protected]> wrote: > > > I thought we needed to support n and n-1. Did that change? > > It was my impression that that’s what we agreed on, as well. > > While 1.2.x -> 1.3.x is the recommended upgrade line, we pledged to > do bugfixes and security issues for 1.2.x. Especially given that the > view engine got a bit of a revamp, I could conceive of a situation > where users wouldn’t want to make the jump to 1.3.x just yet. > > In a post 1.3.x strict-semver, we should have less of that, but for > now I think it is wise to keep 1.2.x up (that said, we can resurrect > the branch at any time, so we may as well leave it out until needed). > > Jan > -- > > > > > > > - benoît > > On May 21, 2013 3:43 AM, "Noah Slater" <[email protected]> wrote: > > > >> Nope. 1.2.x is no longer an actively supported branch. 1.3.x is forwards > >> compatible, and is the recommended upgrade path for anyone on 1.2.x. > >> > >> > >> On 20 May 2013 20:56, Jan Lehnardt <[email protected]> wrote: > >> > >>> Eh sorry, I just noticed that broke CI for 1.2.x which is surely still > an > >>> actively supported branch, shouldn’t we keep that around? > >>> > >>> Jan > >>> -- > >>> > >>> On May 18, 2013, at 22:24 , Jan Lehnardt <[email protected]> wrote: > >>> > >>>> > >>>> > >>>> On 18.05.2013, at 19:56, Noah Slater <[email protected]> wrote: > >>>> > >>>>> Based on the decision made in this thread, it would like to add > >>> something > >>>>> to the release procedure about deleting old branches when we drop > >>> support > >>>>> for that release line. > >>>>> > >>>>> As far as I understand it, no history is lost. The tags still point > to > >>> what > >>>>> we shipped, and the commits still exist in the repository We're just > >>>>> removing the pointers to the tips of the branches. > >>>>> > >>>>> Is this something I need to call another vote for, or am I free to > add > >>> it? > >>>> > >>>> Go for it. > >>>> > >>>>> > >>>>> > >>>>> > >>>>> On 18 May 2013 18:50, Jan Lehnardt <[email protected]> wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On 18.05.2013, at 18:43, Noah Slater <[email protected]> wrote: > >>>>>> > >>>>>>> Unfortunately, the deed is done. What is your reason for wanting to > >>> keep > >>>>>>> them around? > >>>>>> > >>>>>> History :) > >>>>>> > >>>>>> I have plenty of clones, so no worries :) > >>>>>> > >>>>>> Jan > >>>>>> -- > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On 18 May 2013 18:38, Jan Lehnardt <[email protected]> wrote: > >>>>>>> > >>>>>>>> Ah wow, that's what I get for going on vacation with unread > >> threads. > >>>>>>>> > >>>>>>>> I'm major -1 on deleting old release branches, but I'd be happy to > >>> have > >>>>>>>> them moved to an archived repository. For the time being, I'll > keep > >>>>>> them on > >>>>>>>> my GitHub. > >>>>>>>> > >>>>>>>> Cheers > >>>>>>>> Jan > >>>>>>>> -- > >>>>>>>> > >>>>>>>> On 11.05.2013, at 17:31, Noah Slater <[email protected]> wrote: > >>>>>>>> > >>>>>>>>> Thanks guys. > >>>>>>>>> > >>>>>>>>> All the Y.Y.x branches, with the exception of 1.3.x, have been > >>> deleted. > >>>>>>>>> > >>>>>>>>> The following releases have been archived: > >>>>>>>>> > >>>>>>>>> * 1.0.4 > >>>>>>>>> * 1.1.2 > >>>>>>>>> * 1.2.1 > >>>>>>>>> * 1.2.2 > >>>>>>>>> > >>>>>>>>> (Where archived means: removed from our wiki and dist dir.) > >>>>>>>>> > >>>>>>>>> I added the following to our CurrentReleases page: > >>>>>>>>> > >>>>>>>>> CouchDB uses [[http://semver.org/|semantic versioning]], so, in > a > >>>>>>>> nutshell: > >>>>>>>>> > >>>>>>>>> * X.Y.Z equates to major version, minor version, and bugfix > >> version. > >>>>>>>>> * The major version will be incremented every time we make > >> backwards > >>>>>>>>> incompatible changes. > >>>>>>>>> * The minor version will be incremented every time we add > >> backwards > >>>>>>>>> compatible features. > >>>>>>>>> * The patch version will be incremented every time we add > >> backwards > >>>>>>>>> compatible fixes. > >>>>>>>>> > >>>>>>>>> We will support each major version for 12 months. So, if 1.0.0 > was > >>>>>>>> released > >>>>>>>>> on 2010-01-01, then we would features and fixes to it until > >>> 2011-01-01. > >>>>>>>>> After 12 months have passed, we may continue to release fixes for > >>>>>>>> critical > >>>>>>>>> security issues, but these will be in the form of patches. > >>>>>>>>> > >>>>>>>>> Note that the upgrade path for minor versions is to update the > >>> latest > >>>>>>>> minor > >>>>>>>>> version. We will not continue to release bugfix versions for an > >> old > >>>>>> minor > >>>>>>>>> version. That is, 1.1.0 immediately supersedes 1.0.x, and no more > >>> fixes > >>>>>>>>> will be made on the 1.0.x line. Similarly, 1.2.0 immediately > >>> supersedes > >>>>>>>>> 1.1.x. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 7 May 2013 19:34, Noah Slater <[email protected]> wrote: > >>>>>>>>> > >>>>>>>>>> Devs, > >>>>>>>>>> > >>>>>>>>>> We're switching over to time-based releases. > >>>>>>>>>> > >>>>>>>>>> I took a moment to review our existing release branches today, > >> and > >>> I > >>>>>>>> have > >>>>>>>>>> prepared a list of recommendations for you. Please review these > >> and > >>>>>>>> give me > >>>>>>>>>> feedback. > >>>>>>>>>> > >>>>>>>>>> By "drop support" I mean "make official" and while this is > >>> ostensibly > >>>>>>>> the > >>>>>>>>>> case for a few of these, what I _really_ mean is "delete the > >>> branch". > >>>>>> I > >>>>>>>> see > >>>>>>>>>> no reason to keep this stuff around. It would make my life a lot > >>>>>> easier > >>>>>>>> if > >>>>>>>>>> we could clean this stuff up. > >>>>>>>>>> > >>>>>>>>>> I'm not a Git expert, so I am relying on someone to sanity check > >>> this. > >>>>>>>>>> Remember: if we ever want to patch up a security issue in an > >>>>>> unsupported > >>>>>>>>>> release, we will be issuing a patch. So I am assuming what we'll > >>> want > >>>>>>>> to do > >>>>>>>>>> is patch against the last tag for that release line. No need for > >>> the > >>>>>>>> branch > >>>>>>>>>> at all as far as I can tell. > >>>>>>>>>> > >>>>>>>>>> If nobody objects in 72 hours, I will assume lazy consensus and > >>>>>> proceed. > >>>>>>>>>> > >>>>>>>>>> ## 0.10.x line and before > >>>>>>>>>> > >>>>>>>>>> Really old stuff. > >>>>>>>>>> > >>>>>>>>>> Recommendation: > >>>>>>>>>> > >>>>>>>>>> * Drop support of these release lines > >>>>>>>>>> * Delete the branches > >>>>>>>>>> > >>>>>>>>>> ## 0.11.x line > >>>>>>>>>> > >>>>>>>>>> First release: March 2010 (three years old) > >>>>>>>>>> > >>>>>>>>>> Unreleased changes: > >>>>>>>>>> > >>>>>>>>>> * Fix for frequently edited documents in multi-master > deployments > >>>>>> being > >>>>>>>>>> duplicated in _changes and _all_docs. > >>>>>>>>>> > >>>>>>>>>> Recommendation: > >>>>>>>>>> > >>>>>>>>>> * Do not release these changes > >>>>>>>>>> * Drop support of this release line > >>>>>>>>>> * Delete the branch > >>>>>>>>>> > >>>>>>>>>> ## 1.0.x line > >>>>>>>>>> > >>>>>>>>>> First release: July 2010 (three years old) > >>>>>>>>>> > >>>>>>>>>> No unreleased changes. > >>>>>>>>>> > >>>>>>>>>> Recommendation: > >>>>>>>>>> > >>>>>>>>>> * Drop support of this release line > >>>>>>>>>> * Delete the branch > >>>>>>>>>> > >>>>>>>>>> ## 1.1.x line > >>>>>>>>>> > >>>>>>>>>> First release: July 2011 (two years old) > >>>>>>>>>> > >>>>>>>>>> No unreleased changes. > >>>>>>>>>> > >>>>>>>>>> Recommendation: > >>>>>>>>>> > >>>>>>>>>> * Drop support of this release line > >>>>>>>>>> * Delete the branch > >>>>>>>>>> > >>>>>>>>>> ## 1.2.x line > >>>>>>>>>> > >>>>>>>>>> First release: April 2012 (one year old) > >>>>>>>>>> > >>>>>>>>>> No unreleased changes. > >>>>>>>>>> > >>>>>>>>>> 1.3.x line is backwards compatible with 1.2.x. > >>>>>>>>>> > >>>>>>>>>> Recommendation: > >>>>>>>>>> > >>>>>>>>>> * Drop support of this release line > >>>>>>>>>> * Delete the branch > >>>>>>>>>> > >>>>>>>>>> ## 1.3.x line > >>>>>>>>>> > >>>>>>>>>> First release: April 2013 (one month old) > >>>>>>>>>> > >>>>>>>>>> Unreleased changes: > >>>>>>>>>> > >>>>>>>>>> * Whatever bugfixes are on master or in branches right now. > >>>>>>>>>> > >>>>>>>>>> Recommendation: > >>>>>>>>>> > >>>>>>>>>> * Release 1.3.1 this month. > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> NS > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> NS > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> NS > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> NS > >>> > >>> > >> > >> > >> -- > >> NS > >> > > -- NS
