couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Date Wed, 08 May 2013 17:33:43 GMT
I'm +1 on 1.3.0 being the upgrade back for 1.2.anything in general.

If we stick with semver this is the expected path.

On 8 May 2013 18:26, Noah Slater <nslater@apache.org> wrote:
> *Noodles a little while longer...*
>
> In fact, I am not even sure why we recently did that 1.2.2 release.
> Unfortunately, I think we got into the habit of thinking that minor version
> numbers mean breaking changes. Because, in the past, this has sometimes
> been the case. For those people who wanted that fix in the 1.2.2, I should
> have said "please upgrade to 1.3". Unless there are breaking changes that I
> do not know about? (If there is, please tell me. There is nothing in NEWS
> or CHANGES that I can see.)
>
> What are your thoughts on this?
>
>
> On 8 May 2013 18:06, Joan Touzet <wohali@apache.org> wrote:
>
>> I don't know what the Apache stance is on things, but I'm -1 on deleting
>> the 1.2.x branch. "n and n-1" support is fairly common, unless you want
>> to consdier n == HEAD and n-1 == 1.3.x.
>>
>> Otherwise +1.
>>
>> -Joan
>>
>> On Tue, May 07, 2013 at 07:34:14PM +0100, Noah Slater 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
>>
>> --
>> Joan Touzet | joant@atypical.net | wohali everywhere else
>>
>
>
>
> --
> NS

Mime
View raw message