couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Date Sat, 18 May 2013 20:24:53 GMT


On 18.05.2013, at 19:56, Noah Slater <nslater@apache.org> wrote:

> Based on the decision made in this thread, it would like to add something
> to the release procedure about deleting old branches when we drop support
> for that release line.
> 
> As far as I understand it, no history is lost. The tags still point to what
> we shipped, and the commits still exist in the repository  We're just
> removing the pointers to the tips of the branches.
> 
> Is this something I need to call another vote for, or am I free to add it?

Go for it.

> 
> 
> 
> On 18 May 2013 18:50, Jan Lehnardt <jan@apache.org> wrote:
> 
>> 
>> 
>> On 18.05.2013, at 18:43, Noah Slater <nslater@apache.org> wrote:
>> 
>>> Unfortunately, the deed is done. What is your reason for wanting to keep
>>> them around?
>> 
>> History :)
>> 
>> I have plenty of clones, so no worries :)
>> 
>> Jan
>> --
>> 
>> 
>>> 
>>> 
>>> 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
>> 
> 
> 
> 
> -- 
> NS

Mime
View raw message