Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of dch@jsonified.com designates
 209.85.215.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAPaJBx7tn-cD+D8NHDJdbnxXX1h-3aMhXU1sYGpNQs93=mPVkA@mail.gmail.com>
References: 
 <CAPaJBx7tn-cD+D8NHDJdbnxXX1h-3aMhXU1sYGpNQs93=mPVkA@mail.gmail.com>
Date: Tue, 7 May 2013 21:01:29 +0200
Message-ID: 
 <CAL+Y1nv3BmOE7a39Wi39aHbsqdtvUrRSq11Sj88BOVYuvt9L1g@mail.gmail.com>
Subject: Re: [DISCUSS] Release clean-up (delete ALL the branches!)
From: Dave Cottlehuber <dch@jsonified.com>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=089e013d1700e2a3d504dc2571a2

--089e013d1700e2a3d504dc2571a2
Content-Type: text/plain; charset=ISO-8859-1

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.

--089e013d1700e2a3d504dc2571a2--