Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Subject: Re: [DISCUSS] Release clean-up (delete ALL the branches!)
From: Garren Smith <garren@apache.org>
In-Reply-To: 
 <CAPaJBx6P=JcmmrkrgKti=0s2p6E+wauA2SRts9+wM4VqBWyoag@mail.gmail.com>
Date: Wed, 8 May 2013 09:50:36 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <08408DF9-C555-4804-B8EE-5E34B78D4CBB@apache.org>
References: 
 <CAPaJBx7tn-cD+D8NHDJdbnxXX1h-3aMhXU1sYGpNQs93=mPVkA@mail.gmail.com>
 <CAL+Y1nv3BmOE7a39Wi39aHbsqdtvUrRSq11Sj88BOVYuvt9L1g@mail.gmail.com>
 <CAPaJBx6P=JcmmrkrgKti=0s2p6E+wauA2SRts9+wM4VqBWyoag@mail.gmail.com>
To: dev@couchdb.apache.org

+1
On 07 May 2013, at 11:15 PM, Noah Slater <nslater@apache.org> wrote:

> (Note: the work was valuable any how, because master now has an accurate
> record of history.)
> 
> 
> On 7 May 2013 20:01, Dave Cottlehuber <dch@jsonified.com> wrote:
> 
>> On 7 May 2013 20:34, Noah Slater <nslater@apache.org> 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
>>> 
>> 
>> +1.
>> 
>> You might consider tagging the last commit in each branch before you dump
>> it. e.g. you have all those nice changes in NEWS/CHANGES etc that you
>> slaved away on, in the above proposal they'd be lost.
>> 
> 
> 
> 
> -- 
> NS