Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
MIME-Version: 1.0
In-Reply-To: <F74C55C2-DAE0-4B62-BFF6-35BDB4743063@apache.org>
References: 
 <CAPaJBx7tn-cD+D8NHDJdbnxXX1h-3aMhXU1sYGpNQs93=mPVkA@mail.gmail.com>
	<CAPaJBx4iiOKxWLPW4KQsombNMBxE4Sh0nneeSAtg_Nzc6wMf3g@mail.gmail.com>
	<F74C55C2-DAE0-4B62-BFF6-35BDB4743063@apache.org>
Date: Sat, 18 May 2013 18:43:46 +0100
Message-ID: 
 <CAPaJBx5ob6adtXDqthcf62xZCrLyKLi2pEXxFaZMKWL1yKVgaQ@mail.gmail.com>
Subject: Re: [DISCUSS] Release clean-up (delete ALL the branches!)
From: Noah Slater <nslater@apache.org>
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Type: multipart/alternative; boundary=e89a8f83a6af32bfe104dd01a409

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

Unfortunately, the deed is done. What is your reason for wanting to keep
them around?


On 18 May 2013 18:38, Jan Lehnardt <jan@apache.org> 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 <nslater@apache.org> 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 <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
> >
> >
> >
> > --
> > NS
>


-- 
NS

--e89a8f83a6af32bfe104dd01a409--