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
