incubator-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 Tue, 21 May 2013 09:31:36 GMT

On May 21, 2013, at 08:32 , Benoit Chesneau <bchesneau@gmail.com> wrote:

> I thought we needed to support n and n-1. Did that change?

It was my impression that that’s what we agreed on, as well.

While 1.2.x -> 1.3.x is the recommended upgrade line, we pledged to
do bugfixes and security issues for 1.2.x. Especially given that the
view engine got a bit of a revamp, I could conceive of a situation
where users wouldn’t want to make the jump to 1.3.x just yet.

In a post 1.3.x strict-semver, we should have less of that, but for
now I think it is wise to keep 1.2.x up (that said, we can resurrect
the branch at any time, so we may as well leave it out until needed).

Jan
--



> 
> - benoît
> On May 21, 2013 3:43 AM, "Noah Slater" <nslater@apache.org> wrote:
> 
>> Nope. 1.2.x is no longer an actively supported branch. 1.3.x is forwards
>> compatible, and is the recommended upgrade path for anyone on 1.2.x.
>> 
>> 
>> On 20 May 2013 20:56, Jan Lehnardt <jan@apache.org> wrote:
>> 
>>> Eh sorry, I just noticed that broke CI for 1.2.x which is surely still an
>>> actively supported branch, shouldn’t we keep that around?
>>> 
>>> Jan
>>> --
>>> 
>>> On May 18, 2013, at 22:24 , Jan Lehnardt <jan@apache.org> wrote:
>>> 
>>>> 
>>>> 
>>>> 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
>>> 
>>> 
>> 
>> 
>> --
>> NS
>> 


Mime
View raw message