Agreed that major dependency changes might constitute a major number increment.
See this part of the doc I linked: > Each feature release will be supported for 12 months. > Therefor, at any one particular time, there should be four supported feature releases. Does this seem reasonable to you? On 10 April 2013 01:17, Wendall Cada <[email protected]> wrote: > Thanks Noah, this certainly addresses the semantic versioning issues, and > support windows for feature releases, however, I'm still unclear about some > other points. > > How long do major branches get support? Are we forever stuck porting > security fixes to 1.0.x, or does this get retired at some point? I can see > a path moving forward, but what is unclear is how long we will support > older branches. What policy internally is in place that determines what > fixes get back ported, and what just stays broken? > > In my day job, where we use CouchDB heavily, I've been able to update our > application frameworks to the latest CouchDB release with almost reckless > abandon. The api has changed very little (which is a wonderful thing), > allowing for mostly painless upgrading. Personally, I find that > requirements changing and updating at a faster pace than distributions is > more often the limiting factor. This should be reflected in the semantic > versioning as well. For example, say we decide that 1.3.1 needs > spidermonkey 17, and spidermonkey 1.7 support is dropped, this isn't a > patch, and could very well be considered a breaking change. Pretty much any > major external requirement update can pose a potentially breaking change > for packagers where they may be unable to update to the latest version > based on factors outside of their direct control. > > Wendall > > > On 04/09/2013 03:37 PM, Noah Slater wrote: > >> I think our roadmap process answers this: >> >> http://wiki.apache.org/**couchdb/Roadmap_Process<http://wiki.apache.org/couchdb/Roadmap_Process> >> >> Let me know if you think we need something more than this... >> >> >> On 2 April 2013 00:40, Wendall Cada <[email protected]> wrote: >> >> One item missing from this is support of existing versions. I'm not sure >>> if a timeline exists for this, but it should be well understood what the >>> support window will look like for old versions. >>> >>> Wendall >>> >>> >>> On 03/30/2013 12:29 PM, Jan Lehnardt wrote: >>> >>> Hi all, >>>> >>>> It is time to think about how to square the upcoming changes to CouchDB >>>> and the next releases. >>>> >>>> Robert Newson and I hashed out this plan: >>>> >>>> 1. Compile a list of API changes between now and after the BigCouch >>>> merge >>>> (https://issues.apache.org/****jira/browse/COUCHDB-1756<https://issues.apache.org/**jira/browse/COUCHDB-1756> >>>> <https**://issues.apache.org/jira/**browse/COUCHDB-1756<https://issues.apache.org/jira/browse/COUCHDB-1756> >>>> > >>>> >>>> ). >>>> 2. Ship CouchDB 1.4.0 with a `X-CouchDB-Deprecated: true` header for >>>> features that will go away. >>>> 3. Ship CouchDB 2.0.0 with the API changes done, so it is API compatible >>>> with the BigCouch merge. >>>> 4. Merge BigCouch and ship that as 3.0.0. >>>> >>>> Spread over our new quarterly release schedule: >>>> >>>> Early April: 1.3.0. >>>> Early July: 1.4.0. With API deprecation warnings. >>>> Early October: 2.0.0. With API changes. >>>> Early January: 3.0.0. With BigCouch. >>>> >>>> Alternatively, we can ship 1.4.0 and 2.0.0 concurrently, so the BigCouch >>>> merge work doesn’t get a chance to get stale: >>>> >>>> Early April: 1.3.0. >>>> Early July: 1.4.0. With API deprecation warnings. >>>> Early July: 2.0.0. With API changes. >>>> Early October: 3.0.0. With BigCouch. >>>> >>>> Monthly minor- and patch-level-versions will continue as usual. >>>> >>>> If we want to ship new features before BigCouch but after 1.4.0, we can >>>> roll 1.5.0 / 2.1.0 before 3.0.0. >>>> >>>> Anything up to the BigCouch merge should be trivial, so we can be >>>> confident we get that right (modulo forgetting to deprecate something). >>>> If >>>> the actual technical issues to get BigCouch merged aren’t done by >>>> October >>>> in the way we are satisfied with shipping, we can wait to ship 3.0.0 >>>> until >>>> we think it is ready. >>>> >>>> In an ideal world, if 2.0.0 and BigCouch merge are API compatible, we >>>> *could* ship BigCouch in say, 2.5.0 or something, but I think the >>>> underlying things change enough to warrant a full major version >>>> increase. >>>> >>>> The only open question I’d have is how to square that against the >>>> ongoing >>>> work on bringing rcouch in. I hope Benoit can comment on this. >>>> >>>> Bikeshed away! :) >>>> >>>> Jan >>>> -- >>>> >>>> >>>> >> > -- NS
