Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
MIME-Version: 1.0
In-Reply-To: <AD369360-68F4-4200-88CE-5D2D544A0946@apache.org>
References: 
 <CAPaJBx7tn-cD+D8NHDJdbnxXX1h-3aMhXU1sYGpNQs93=mPVkA@mail.gmail.com>
	<CAPaJBx4iiOKxWLPW4KQsombNMBxE4Sh0nneeSAtg_Nzc6wMf3g@mail.gmail.com>
	<F74C55C2-DAE0-4B62-BFF6-35BDB4743063@apache.org>
	<CAPaJBx5ob6adtXDqthcf62xZCrLyKLi2pEXxFaZMKWL1yKVgaQ@mail.gmail.com>
	<68A781FC-9735-4FF0-BBB1-3828D96FC4B7@apache.org>
	<CAPaJBx7n_mS6mP5aerW8b+ONY5h+yyfEupTJ7-6v8ftNT_8i5Q@mail.gmail.com>
	<A5001098-0DB5-4D72-BFC5-DA3FFBF0049A@apache.org>
	<24857C82-2D18-4211-A33A-D25DC096EDFB@apache.org>
	<CAPaJBx72kB_=5bMRwOU6xx_5MgwQgq6EJXWgiCji5p51CmEW+A@mail.gmail.com>
	<CAJNb-9qOjk4bK=3-UHfsVGx-06H0e1QA7_ujmcwFOfFceUcqXA@mail.gmail.com>
	<290BAA7E-43E5-4993-8CA0-D8983BF0964A@apache.org>
	<CAPaJBx4pdO3NwKCmVMLrJFzdsz0bQkDVwdFSZ+k4aAohPtM5Fg@mail.gmail.com>
	<46C7D548-FB0B-4105-8E43-A63D66D9AF1D@apache.org>
	<CAPaJBx5fycbiwnmuT9v+wQHUoB5jOK7WL6dON8ArrcTh7M+Ymg@mail.gmail.com>
	<BF7C4DC6-740B-4EE7-BFA1-B6416414806D@apache.org>
	<CAPaJBx4rwK_FfY8osX-+8tOa9AhV-8ZwgUhZ3d9SnR-pPq6j9g@mail.gmail.com>
	<AD369360-68F4-4200-88CE-5D2D544A0946@apache.org>
Date: Tue, 21 May 2013 18:29:15 +0100
Message-ID: 
 <CAPaJBx7b6j2imtM8AuWSHnCe_dRUBdqevjctG6zgGsHj8QuOjg@mail.gmail.com>
Subject: Re: [DISCUSS] Release clean-up (delete ALL the branches!)
From: Noah Slater <nslater@apache.org>
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Type: multipart/alternative; boundary=e89a8f83a6afd8f12704dd3dc911

--e89a8f83a6afd8f12704dd3dc911
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 21 May 2013 18:05, Jan Lehnardt <jan@apache.org> wrote:

>
> On May 21, 2013, at 18:30 , Noah Slater <nslater@apache.org> 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 tha=
t
> > 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 th=
e
> > roadmap process. [1] This moves our support plan to one that is both ti=
me
> > 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=92t like the idea that we change rules
> from under a release that we did promise at release time to support for
> 12 months.
>

I don't think we've ever made a 12 month promise before. The wiki diff you
linked to doesn't mention a timeline, it just mentions we'll support n-1.
So, I guess, technically, yes, we're breaking a promise. I'm just not
convinced that it's a very important promise. ;)

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 aga=
in
> I do support), I just don=92t like new rules applied to old releases.


Okay, sure. As you can see from the original thread, I was a
little hesitant to do this, because I didn't understand the complexities of
the 1.2.x -> 1.3.x migration (this being the first switchover to our new
system). In many respects, a little bit of friction/pain is unsurprising.

> 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 upgra=
de
> > 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 th=
is
> > 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.


Hmm. Where? I don't think we ever said that. The promise was "n-1". Which I
agree we're breaking. I just don't think it's important, because of the
likely 1.2.x -> 1.3.x upgrade path. (I agree, if this isn't a legitimate
upgrade path, then this is a problem. It seems we don't know for sure
though =97 hence my suggestion to wait and see.)


> 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. =97 I understand we don=92t have a legal contract with ou=
r
> users, but we have a trust relationship here that we potentially damage.
>

Agreed. I understand your metaphors. :) I don't want to damage trust
either. I think if there are legitimate problems moving from 1.2.2 to 1.3.0
then we absolutely handle that and support our users. If not, then we
should be able to say "please move to 1.3.0."

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 littl=
e
> bit understandable?
>

Absolutely.


> Also, I believe we already have spent entirely too much time on this. I
> don=92t 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=92=
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.
>

Cool. Sorry if you thought the thread was headed in that direction. I think
this is a healthy conversation to be having. And I think we've both made
reasonable arguments, and ended up in agreement. :)

--=20
NS

--e89a8f83a6afd8f12704dd3dc911--