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? Cheers Jan --
