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 wenda...@apache.org wrote:
One item missing from this is support of existing versions. I'm not sure
if a
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
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
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
I'm probably missing something here, but why can't we land BigCouch in a
single dual-release?
Timeline:
* BigCouch lands on master
* No date — it happens when it happens
* We simultaneously release 2.0.0 and 1.X.0
* This happens at the next available regular release date
* There's _no_ reason, that I can see, that this deprecation has _to
happen_ 3 months prior.
On 31 March 2013 17:40, Noah Slater nsla...@apache.org wrote:
I'm probably missing something here, but why can't we land BigCouch in a
single dual-release?
Timeline:
* BigCouch lands on master
On Mar 31, 2013, at 18:41 , Noah Slater nsla...@apache.org wrote:
* There's _no_ reason, that I can see, that this deprecation has _to
happen_ 3 months prior.
Yeah, that works too, it is the same procedure, just compressed some
more. I don’t think we intended anything special with an
From an organisational point of view, it seems much more simple to me to do
this simultaneous deprecate bits in the 1.x line while starting a new 2.x
line thing. The bit I don't know is whether this makes sense from a
technical point of view. Your plan, for instance, spaces out the API
changes and
Actually. Sorry. Let me reconsider that actually.
I think the important thing I am getting at is that if we can do the API
changes and the BigCouch merge at the same time, then we have two important
releases to do:
* 1.x line with the depreciation warnings
* 2.x line with the new stuff
* Uh, _ deprecation_ warnings. ;)
On 31 March 2013 18:06, Noah Slater nsla...@apache.org wrote:
Actually. Sorry. Let me reconsider that actually.
I think the important thing I am getting at is that if we can do the API
changes and the BigCouch merge at the same time, then we have two
On Mar 31, 2013, at 19:06 , Noah Slater nsla...@apache.org wrote:
Actually. Sorry. Let me reconsider that actually.
I think the important thing I am getting at is that if we can do the API
changes and the BigCouch merge at the same time, then we have two important
releases to do:
*
I understand what you are saying, and I agree with it.
But the API only release seems unnecessary to me. If the version numbers
are not important (and they are not) then let's just treat them that way
and ship BigCouch in 2.0.0. Actually going out of our way to make a bunch
of (otherwise
On Mar 30, 2013, at 20:44 , Benoit Chesneau bchesn...@gmail.com wrote:
On Sat, Mar 30, 2013 at 8:29 PM, Jan Lehnardt j...@apache.org 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:
On Mar 31, 2013, at 20:06 , Noah Slater nsla...@apache.org wrote:
I understand what you are saying, and I agree with it.
But the API only release seems unnecessary to me. If the version numbers
are not important (and they are not) then let's just treat them that way
and ship BigCouch in
If the BigCouch merge is ready for the next feature release date, then I
would probably need a little more convincing if the proposal was to delay
it by 3 months so that we could cut 2.0.0 to make a point about version
numbers. If BigCouch is not ready by the next feature release date, then I
have
On Mar 31, 2013, at 20:10 , Noah Slater nsla...@apache.org wrote:
If the BigCouch merge is ready for the next feature release date, then I
would probably need a little more convincing if the proposal was to delay
it by 3 months so that we could cut 2.0.0 to make a point about version
On Sat, Mar 30, 2013 at 8:29 PM, Jan Lehnardt j...@apache.org wrote:
Bikeshed away! :)
Will there be discussion on API changes for BigCouch stuff? I don't
really have a clue on how BigCouch is different from CouchDB exactly,
all I know is it does some clustering and that's why some things are
On Mar 31, 2013, at 21:32 , Dirkjan Ochtman dirk...@ochtman.nl wrote:
On Sat, Mar 30, 2013 at 8:29 PM, Jan Lehnardt j...@apache.org wrote:
Bikeshed away! :)
Will there be discussion on API changes for BigCouch stuff? I don't
really have a clue on how BigCouch is different from CouchDB
On Sun, Mar 31, 2013 at 9:42 PM, Jan Lehnardt j...@apache.org wrote:
We will be collecting things here:
https://issues.apache.org/jira/browse/COUCHDB-1756
There is an (incomplete) list of differences down on:
http://bigcouch.cloudant.com/api
Robert Paul et.al will help getting the
On Mar 31, 2013, at 21:48 , Dirkjan Ochtman dirk...@ochtman.nl wrote:
On Sun, Mar 31, 2013 at 9:42 PM, Jan Lehnardt j...@apache.org wrote:
We will be collecting things here:
https://issues.apache.org/jira/browse/COUCHDB-1756
There is an (incomplete) list of differences down on:
It's not going away. It still exists on the back end interface, but it's the
admins job to purge at all replicas. The AP clustering model cannot guarantee a
cluster-wide purge.
The reason BigCouch doesn't support purge is that we need to synchronise
replicas of the same shard. Purging removes
That said, it would be great to reap state that we will never need again, it
just mustn't happen before every replica has seen it.
Sent from my iPhone
On 31 Mar 2013, at 20:55, Jan Lehnardt j...@apache.org wrote:
On Mar 31, 2013, at 21:48 , Dirkjan Ochtman dirk...@ochtman.nl wrote:
On
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).
2. Ship CouchDB
On Sat, Mar 30, 2013 at 8:29 PM, Jan Lehnardt j...@apache.org 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
24 matches
Mail list logo
