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 15:05:28 GMT

On May 21, 2013, at 15:20 , Noah Slater <nslater@apache.org> wrote:

> This was discussed in the following thread:
> 
> "[DISCUSS] Simplify active release branches (Was: Re: [DISCUSS] Git
> workflow)"

Again, I missed this and the vote due to vacation and I only skimmed
the thread in catch-up mode.

> — http://markmail.org/message/5edirnhli43g7lt6
> 
> At the start of this thread, I put forward my rationale for dropping
> support for 1.2.x (namely, that 1.3.x should be forwards compatible with
> 1.2.x), and nobody objected.

I formally object now.


> I've also made an adjustment to the "n + n-1" concept, more inline with
> both the Dublin discussion and the points about semver that Dale brought
> up, and I added it to the wiki, as previously noted in this thread.

We can’ retroactively do that for releases that aren’t part of the new
plan (e.g. 1.2.x) where the circumstances of strict semver don’t apply.

> 
> We will support each major version for 12 months. So, if 1.0.0 was released
>> on 2010-01-01, then we would add 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 actual patches.
> 
> 
> 
> Note that the upgrade path for minor versions is to update the latest minor
>> version. We will not continue to release patch 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.
> 
> 
> — http://wiki.apache.org/couchdb/CurrentReleases
> 
> I appreciate that this is the first time we've done this, so it might be a
> little surprising to people. (Though, I believe, this has been the plan for
> a good 12 months.) Let's closely monitor the situation, and if any issues
> crop up, we deal with them.

I agree to do this going forward, but I found it odd to drop a branch that
we currently consider as being supported, that is all.

I stand by my previous suggestion to resurrect 1.2.x in case we need to do
a follow-up release if the scenario warrants that a user can’t upgrade to
1.3.x.

Jan
--





> 
> 
> On 21 May 2013 10:31, Jan Lehnardt <jan@apache.org> wrote:
> 
>> 
>> 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
>>>> 
>> 
>> 
> 
> 
> -- 
> NS


Mime
View raw message