incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Date Tue, 21 May 2013 16:12:37 GMT

On May 21, 2013, at 17:31 , Noah Slater <> wrote:

> On 21 May 2013 16:05, Jan Lehnardt <> wrote:
>> Again, I missed this and the vote due to vacation and I only skimmed
>> the thread in catch-up mode.
> Understood. I was providing you with context.

Yup, cheers :)

>>> 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 can, because all I'm suggesting is:
> * We identify each release line that is not upgradable to the next, and
> * That we support these release lines for 12 months
> This strategy works no matter what versioning system we use.
>> 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 dropped it because we decided not to support it.
>> 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.
> There is no indication in 1.3.x that there are breaking changes over 1.2.x.
> How likely is it, do you think, that there is legitimate reason not to
> upgrade?
> Moreover, even the upgrade path from 1.2.x to 1.3.x is problematic, the
> 1.2.x line is now 12 months old, so according to our 12 months support
> plan, it is time that we drop support anyway.

So we made the decision to support major release lines instead of just single
releases?[1] Again, I am all game with that going forward, but we released 1.2.2
earlier this year under the premise that that *release* was supported for 12
months, not just the 1.2.x line.

I just imagine the scenario as a user on the 1.2.2 release, having installed
it with the premise that we’d support that particular release for 12 months
only to find out that we drop support for it after just a few month claiming
new rules.

I’m not saying we can’t do that, we can do whatever the hell we want, but I
don’t like the idea that our uses can get into a situation where they feel
screwed over.

View raw message