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