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
