Why 60 days. Why not "when it"s ready" and by it's I mean doc & cors. if it's part of 1.3 .
- benoit On Tue, Nov 13, 2012 at 8:28 PM, Jan Lehnardt <[email protected]> wrote: > 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 > -- > >
