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 17:05:27 GMT

On May 21, 2013, at 18:30 , Noah Slater <> wrote:

> I don't want that either. Let's roll with the punches here and see what
> happens. If people ask us what the situation is, we say the recommended
> upgrade path is 1.2.2 -> 1.3.x. If we run into problems with that, lets
> deal with it at that point. One option is to release actual patches that
> you can apply to the 1.2.2 tag. Or we could just do another release.
> And yep, I updated that page to better reflect the discussion around the
> roadmap process. [1] This moves our support plan to one that is both time
> based and centred around major release lines. This works well with semver.
> The promise is that every major version is supported (i.e. we add features
> and bug fixes) for 12 months. That is easy to understand.

I understand all that, I just don’t like the idea that we change rules
from under a release that we did promise at release time to support for
12 months.

> Note also how great this is for our release procedure. Before we've been
> running 1.1.x, and 1.2.x at the same time. Not for any particular reason.
> Just because. We were doing it even if there were no breaking changes!
> Nonsensical. Dale's original email was so great. I can't believe I never
> realised this before in the half a decade I've been cutting releases. Heh.

Yes, and going forward that is all great, but the differences between 1.2.x
and 1.3.x may warrant a new major version under the new regime (which again
I do support), I just don’t like new rules applied to old releases.

> For 1.2.x and older lines, I went through them one by one in the original
> email in this thread, to see a) how old they were and b) what the upgrade
> path was. Based on that work, 1.1.x is two years old, so I suggested we
> drop it. And 1.2.x is both one year old, and has an (though it seems this
> isn't as clear cut as we thought) upgrade path to 1.3.x.

Yes, and that makes the least sense to me. At the time of the release of
1.2.2 we stated that we support that release for 12 months earlier *this*
year. So if we are looking at a transition, and if we were wanting to try
to not break any promises we made just a few months ago, I’d look at the
*latest* release in a particular line and nuke everything older than 12
months (now that’d include the 1.1.x line, but I’d be in favour of
retiring that, as the last fix was as security fix).

This whole argument reads to me like deciding that a tax rate of 50% is
raised to 75% retroactively to five years ago and all individuals and
businesses need to pay the missing 25% retroactively. I understand that
there are some backdating situations in the real world, but they are
rarely as substantial. All I am in favour of is using the 75% tax
*from now on*, so everyone can adjust their accounting accordingly.

Or more concretely, if you buy some household device with a two year
warranty and three months in the manufacturer decides to stop supporting
it from now on. — I understand we don’t have a legal contract with our
users, but we have a trust relationship here that we potentially damage.

I think this boils down to not wanting to apply new rules to old releases
that were done when other rules were applicable. Is that at least a little
bit understandable?

Also, I believe we already have spent entirely too much time on this. I
don’t want to turn this into a who is right and who is righter endless-
thread. I understand how we arrived at the current situation and I don’t
think anyone in particular is to blame for this. I just think the wrong
decision was made with regards to existing supported releases and I think
the proposed plan (resurrect 1.2.x when/if required) is enough to let
this rest for now until a situation arises that requires us to look
at 1.2.x.


> [1]
> On 21 May 2013 17:12, Jan Lehnardt <> wrote:
>> 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.
>> Jan
>> --
>> [1]:
> -- 
> NS

View raw message