couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Date Thu, 23 May 2013 12:13:16 GMT
Thanks Alex. These should point to tags. I'll update them.


On 23 May 2013 10:34, Alexander Shorin <kxepal@gmail.com> wrote:

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



-- 
NS

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