incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Date Sat, 11 May 2013 16:31:18 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message