couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <kxe...@gmail.com>
Subject Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Date Thu, 23 May 2013 09:34:55 GMT
Side effect note: links on old blog posts are broken. Example:
https://blogs.apache.org/couchdb/entry/apache_couchdb_1_2_0

NEWS: http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=blob_plain;f=NEWS;hb=1.2.x
CHANGES: https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=blob_plain;f=CHANGES;hb=1.2.x
git commit log:
https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=log;h=1.2.x
--
,,,^..^,,,


On Tue, May 21, 2013 at 9:29 PM, Noah Slater <nslater@apache.org> wrote:
> 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 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.
>>
>
> 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 again
>> I do support), I just don’t 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 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.
>
>
> 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 — 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. — I understand we don’t have a legal contract with our
>> 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 little
>> bit understandable?
>>
>
> Absolutely.
>
>
>> 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.
>>
>
> 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. :)
>
> --
> NS

Mime
View raw message