Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: error (athena.apache.org: local policy)
Subject: Re: [DISCUSS] Release clean-up (delete ALL the branches!)
References: 
 <CAPaJBx7tn-cD+D8NHDJdbnxXX1h-3aMhXU1sYGpNQs93=mPVkA@mail.gmail.com>
 <CAPaJBx4iiOKxWLPW4KQsombNMBxE4Sh0nneeSAtg_Nzc6wMf3g@mail.gmail.com>
 <F74C55C2-DAE0-4B62-BFF6-35BDB4743063@apache.org>
 <CAPaJBx5ob6adtXDqthcf62xZCrLyKLi2pEXxFaZMKWL1yKVgaQ@mail.gmail.com>
From: Jan Lehnardt <jan@apache.org>
Content-Type: text/plain;
	charset=us-ascii
In-Reply-To: 
 <CAPaJBx5ob6adtXDqthcf62xZCrLyKLi2pEXxFaZMKWL1yKVgaQ@mail.gmail.com>
Message-Id: <68A781FC-9735-4FF0-BBB1-3828D96FC4B7@apache.org>
Date: Sat, 18 May 2013 18:50:13 +0100
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)


On 18.05.2013, at 18:43, Noah Slater <nslater@apache.org> 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
--


>=20
>=20
> On 18 May 2013 18:38, Jan Lehnardt <jan@apache.org> wrote:
>=20
>> Ah wow, that's what I get for going on vacation with unread threads.
>>=20
>> 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 o=
n
>> my GitHub.
>>=20
>> Cheers
>> Jan
>> --
>>=20
>> On 11.05.2013, at 17:31, Noah Slater <nslater@apache.org> wrote:
>>=20
>>> Thanks guys.
>>>=20
>>> All the Y.Y.x branches, with the exception of 1.3.x, have been deleted.
>>>=20
>>> The following releases have been archived:
>>>=20
>>> * 1.0.4
>>> * 1.1.2
>>> * 1.2.1
>>> * 1.2.2
>>>=20
>>> (Where archived means: removed from our wiki and dist dir.)
>>>=20
>>> I added the following to our CurrentReleases page:
>>>=20
>>> CouchDB uses [[http://semver.org/|semantic versioning]], so, in a
>> nutshell:
>>>=20
>>> * 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.
>>>=20
>>> 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.
>>>=20
>>> 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 mino=
r
>>> 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.
>>>=20
>>>=20
>>>=20
>>> On 7 May 2013 19:34, Noah Slater <nslater@apache.org> wrote:
>>>=20
>>>> Devs,
>>>>=20
>>>> We're switching over to time-based releases.
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>>=20
>>>> 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 unsupporte=
d
>>>> 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.
>>>>=20
>>>> If nobody objects in 72 hours, I will assume lazy consensus and proceed=
.
>>>>=20
>>>> ## 0.10.x line and before
>>>>=20
>>>> Really old stuff.
>>>>=20
>>>> Recommendation:
>>>>=20
>>>> * Drop support of these release lines
>>>> * Delete the branches
>>>>=20
>>>> ## 0.11.x line
>>>>=20
>>>> First release: March 2010 (three years old)
>>>>=20
>>>> Unreleased changes:
>>>>=20
>>>> * Fix for frequently edited documents in multi-master deployments being=

>>>>   duplicated in _changes and _all_docs.
>>>>=20
>>>> Recommendation:
>>>>=20
>>>> * Do not release these changes
>>>> * Drop support of this release line
>>>> * Delete the branch
>>>>=20
>>>> ## 1.0.x line
>>>>=20
>>>> First release: July 2010 (three years old)
>>>>=20
>>>> No unreleased changes.
>>>>=20
>>>> Recommendation:
>>>>=20
>>>> * Drop support of this release line
>>>> * Delete the branch
>>>>=20
>>>> ## 1.1.x line
>>>>=20
>>>> First release: July 2011 (two years old)
>>>>=20
>>>> No unreleased changes.
>>>>=20
>>>> Recommendation:
>>>>=20
>>>> * Drop support of this release line
>>>> * Delete the branch
>>>>=20
>>>> ## 1.2.x line
>>>>=20
>>>> First release: April 2012 (one year old)
>>>>=20
>>>> No unreleased changes.
>>>>=20
>>>> 1.3.x line is backwards compatible with 1.2.x.
>>>>=20
>>>> Recommendation:
>>>>=20
>>>> * Drop support of this release line
>>>> * Delete the branch
>>>>=20
>>>> ## 1.3.x line
>>>>=20
>>>> First release: April 2013 (one month old)
>>>>=20
>>>> Unreleased changes:
>>>>=20
>>>> * Whatever bugfixes are on master or in branches right now.
>>>>=20
>>>> Recommendation:
>>>>=20
>>>> * Release 1.3.1 this month.
>>>>=20
>>>> Thanks,
>>>>=20
>>>> --
>>>> NS
>>>=20
>>>=20
>>>=20
>>> --
>>> NS
>=20
>=20
>=20
> --=20
> NS