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
