Thanks Alex. These should point to tags. I'll update them.
On 23 May 2013 10:34, Alexander Shorin <[email protected]> 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 <[email protected]> wrote: > > On 21 May 2013 18:05, Jan Lehnardt <[email protected]> wrote: > > > >> > >> On May 21, 2013, at 18:30 , Noah Slater <[email protected]> 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
