couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Date Tue, 21 May 2013 16:30:57 GMT
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.

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.

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.


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]:


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message