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
