Ok, cleared up. Thanks Noah.
Wendall
On 04/09/2013 05:54 PM, Noah Slater wrote:
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
--
