couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Let’s ship 1.3.0 now.
Date Tue, 13 Nov 2012 19:28:57 GMT
Hey all,

when we set out to ship 1.3.0, we thought the cors and docs 
branches were just around the corner. That was a couple of 
weeks ago. We are just starting with this, but the whole 
idea of time-based releases is that we do not wait for 
feature branches to be ready.

I’d like to propose that we ignore everything we’ve said
before and do the following:

 - ship 1.3.0 as reflected in the 1.3.x branch now.
 - merge docs and cors to master whenever they are ready.
 - branch 1.4.x 60 days from now.
 - ship 1.4.0 90 days from now.

(by “ship” I mean “start the usual release procedure”)

Why call it 1.3.0 and not 1.2.1?

Excellent question. Quoting NEWS:

> * The source code repository was migrated from SVN to Git.
> * Added view request duration to Futon.
> * Speedup in the communication with external view servers.
> * Fixed unnecessary conflict when deleting and creating a
>   document in the same batch.
> * New and updated passwords are hashed using PBKDF2.
> * Fix various bugs in the URL rewriter when recursion is involved.
> * Added Server-Sent Events protocol to db changes API.
> * Moved the JS test suite to the CLI
> * Make password hashing synchronous when using the /_config/admins API.
> * Added utc_id UUID algorithm.
> * encode database name during URL rewriting.
> * Include user name in show/list ETags.

A bunch of new minor features (PBKDF2, utc_id UUIDs,
Event Source _changes) and infrastructure changes
(Git move, CLI tests) all make me think this is a
1.3.0, not a bugfix release like 1.2.1 would be.

But, 1.3.0 won’t have any flagship features! Yup, 
from now on we’ll ship many more of these minor
releases, we start getting used to it :)

What do you think?


View raw message