Let’s ship 1.3.0 now.

[Jan Lehnardt <ja...@apache.org>]

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
-- 

Re: Let’s ship 1.3.0 now.

[Octavian Damiean <ma...@gmail.com>]

+1 on releasing 1.3 already and +1 on time based releases.

On Nov 14, 2012 4:18 AM, "Randall Leeds" <ra...@gmail.com> wrote:
>
> +1
>
> We can do a round up of the status of 1.3 blockers during this week's
> meeting and get the focus around it, make sure there's actions for
everyone
> who needs them for everything to get done.
>
>
> On Tue, Nov 13, 2012 at 6:56 PM, Paul Davis <paul.joseph.davis@gmail.com
>wrote:
>
> > The point of not including cors in 1.3 is precisely so we're not rushing
> > things. Historically we have had a habit of wanting "the next big
feature"
> > in "the next big release" which tends to make our releases drag out a
bit
> > as we wait on volunteers to work through the big features. The idea
behind
> > time based releases is that we'll have releases regularly and then won't
> > need to rush to get big features done quickly because the delay between
> > releases will only be a couple months instead of in the 6-12 month
range.
> >
> > +1 on releasing (assuming that all blocker bugs are cleared, I haven't
> > checked the list lately) without CORS and docs.
> >
> >
> > On Tue, Nov 13, 2012 at 7:07 PM, john.tiger <john.tigernassau@gmail.com
> > >wrote:
> >
> > > this feels rushed - not a good thing with an enterprise thing like a
db -
> > > does couch have big users that need the as is 1.3 features asap or
even
> > > sponsors that are wanting to ship every 3 mos regardless ?  If not,
why
> > not
> > > wait and rally troops to make sure cors features are set,
documentation
> > is
> > > done, and some compiling issues are resolved - maybe the committee has
> > > other reasons, but 3 mos seems really quick for an enterprise thing
like
> > a
> > > db.
> > >
> > > Others mlge may vary but we want to use the cors feature - could care
> > less
> > > about a 1.3 without it
> > >
> > >
> > >
> > >
> > > On 11/13/2012 01:08 PM, Jan Lehnardt wrote:
> > >
> > >> On Nov 13, 2012, at 20:53 , Benoit Chesneau <bc...@gmail.com>
> > wrote:
> > >>
> > >>  On Tue, Nov 13, 2012 at 8:51 PM, Jan Lehnardt <ja...@apache.org>
wrote:
> > >>>
> > >>>  if it's part of 1.3.
> > >>>>>
> > >>>> The point of this email is to decouple cors & docs from 1.3.0.
> > >>>>
> > >>>>
> > >>>>  I forgot a "not" obviously.. Sorry for that
> > >>>
> > >> Clarified via IRC:
> > >>
> > >> [21:00:26] <benoitc> well was just me trying to ask "do we really
want
> > to
> > >> ship at least without docs? "
> > >> [21:00:39] <benoitc> but i'm fine with both
> > >> [21:00:40] <+jan____> ah, I’d say yes.
> > >> [21:01:12] <benoitc> i wonder if we couldn't put the doc online for
1.3
> > >> at least
> > >> [21:01:39] <benoitc> since that part can be easily done
> > >> http://rcouch.org/docs/
> > >> [21:01:58] <+jan____> sure, why not, that’s completely unrelated to
the
> > >> release
> > >> [21:02:18] <benoitc> indeed
> > >>
> > >> Cheers
> > >> Jan
> > >>
> > >
> > >
> >

Re: Let’s ship 1.3.0 now.

[Randall Leeds <ra...@gmail.com>]

+1

We can do a round up of the status of 1.3 blockers during this week's
meeting and get the focus around it, make sure there's actions for everyone
who needs them for everything to get done.


On Tue, Nov 13, 2012 at 6:56 PM, Paul Davis <pa...@gmail.com>wrote:

> The point of not including cors in 1.3 is precisely so we're not rushing
> things. Historically we have had a habit of wanting "the next big feature"
> in "the next big release" which tends to make our releases drag out a bit
> as we wait on volunteers to work through the big features. The idea behind
> time based releases is that we'll have releases regularly and then won't
> need to rush to get big features done quickly because the delay between
> releases will only be a couple months instead of in the 6-12 month range.
>
> +1 on releasing (assuming that all blocker bugs are cleared, I haven't
> checked the list lately) without CORS and docs.
>
>
> On Tue, Nov 13, 2012 at 7:07 PM, john.tiger <john.tigernassau@gmail.com
> >wrote:
>
> > this feels rushed - not a good thing with an enterprise thing like a db -
> > does couch have big users that need the as is 1.3 features asap or even
> > sponsors that are wanting to ship every 3 mos regardless ?  If not, why
> not
> > wait and rally troops to make sure cors features are set, documentation
> is
> > done, and some compiling issues are resolved - maybe the committee has
> > other reasons, but 3 mos seems really quick for an enterprise thing like
> a
> > db.
> >
> > Others mlge may vary but we want to use the cors feature - could care
> less
> > about a 1.3 without it
> >
> >
> >
> >
> > On 11/13/2012 01:08 PM, Jan Lehnardt wrote:
> >
> >> On Nov 13, 2012, at 20:53 , Benoit Chesneau <bc...@gmail.com>
> wrote:
> >>
> >>  On Tue, Nov 13, 2012 at 8:51 PM, Jan Lehnardt <ja...@apache.org> wrote:
> >>>
> >>>  if it's part of 1.3.
> >>>>>
> >>>> The point of this email is to decouple cors & docs from 1.3.0.
> >>>>
> >>>>
> >>>>  I forgot a "not" obviously.. Sorry for that
> >>>
> >> Clarified via IRC:
> >>
> >> [21:00:26] <benoitc> well was just me trying to ask "do we really want
> to
> >> ship at least without docs? "
> >> [21:00:39] <benoitc> but i'm fine with both
> >> [21:00:40] <+jan____> ah, I’d say yes.
> >> [21:01:12] <benoitc> i wonder if we couldn't put the doc online for 1.3
> >> at least
> >> [21:01:39] <benoitc> since that part can be easily done
> >> http://rcouch.org/docs/
> >> [21:01:58] <+jan____> sure, why not, that’s completely unrelated to the
> >> release
> >> [21:02:18] <benoitc> indeed
> >>
> >> Cheers
> >> Jan
> >>
> >
> >
>

Re: Let’s ship 1.3.0 now.

[Paul Davis <pa...@gmail.com>]

The point of not including cors in 1.3 is precisely so we're not rushing
things. Historically we have had a habit of wanting "the next big feature"
in "the next big release" which tends to make our releases drag out a bit
as we wait on volunteers to work through the big features. The idea behind
time based releases is that we'll have releases regularly and then won't
need to rush to get big features done quickly because the delay between
releases will only be a couple months instead of in the 6-12 month range.

+1 on releasing (assuming that all blocker bugs are cleared, I haven't
checked the list lately) without CORS and docs.


On Tue, Nov 13, 2012 at 7:07 PM, john.tiger <jo...@gmail.com>wrote:

> this feels rushed - not a good thing with an enterprise thing like a db -
> does couch have big users that need the as is 1.3 features asap or even
> sponsors that are wanting to ship every 3 mos regardless ?  If not, why not
> wait and rally troops to make sure cors features are set, documentation is
> done, and some compiling issues are resolved - maybe the committee has
> other reasons, but 3 mos seems really quick for an enterprise thing like a
> db.
>
> Others mlge may vary but we want to use the cors feature - could care less
> about a 1.3 without it
>
>
>
>
> On 11/13/2012 01:08 PM, Jan Lehnardt wrote:
>
>> On Nov 13, 2012, at 20:53 , Benoit Chesneau <bc...@gmail.com> wrote:
>>
>>  On Tue, Nov 13, 2012 at 8:51 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>>
>>>  if it's part of 1.3.
>>>>>
>>>> The point of this email is to decouple cors & docs from 1.3.0.
>>>>
>>>>
>>>>  I forgot a "not" obviously.. Sorry for that
>>>
>> Clarified via IRC:
>>
>> [21:00:26] <benoitc> well was just me trying to ask "do we really want to
>> ship at least without docs? "
>> [21:00:39] <benoitc> but i'm fine with both
>> [21:00:40] <+jan____> ah, I’d say yes.
>> [21:01:12] <benoitc> i wonder if we couldn't put the doc online for 1.3
>> at least
>> [21:01:39] <benoitc> since that part can be easily done
>> http://rcouch.org/docs/
>> [21:01:58] <+jan____> sure, why not, that’s completely unrelated to the
>> release
>> [21:02:18] <benoitc> indeed
>>
>> Cheers
>> Jan
>>
>
>

Re: Let’s ship 1.3.0 now.

[Robert Newson <rn...@apache.org>]

CouchDB 1.2 was released in April, we've certainly not rushed 1.3. :)

Releasing on a regular basis seems sensible, and the group doing the work
came to that conclusion together, it doesn't oblige you to upgrade to a
release that doesn't contain features or fixes you need.

B.


On 14 November 2012 00:07, john.tiger <jo...@gmail.com> wrote:

> this feels rushed - not a good thing with an enterprise thing like a db -
> does couch have big users that need the as is 1.3 features asap or even
> sponsors that are wanting to ship every 3 mos regardless ?  If not, why not
> wait and rally troops to make sure cors features are set, documentation is
> done, and some compiling issues are resolved - maybe the committee has
> other reasons, but 3 mos seems really quick for an enterprise thing like a
> db.
>
> Others mlge may vary but we want to use the cors feature - could care less
> about a 1.3 without it
>
>
>
>
> On 11/13/2012 01:08 PM, Jan Lehnardt wrote:
>
>> On Nov 13, 2012, at 20:53 , Benoit Chesneau <bc...@gmail.com> wrote:
>>
>>  On Tue, Nov 13, 2012 at 8:51 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>>
>>>  if it's part of 1.3.
>>>>>
>>>> The point of this email is to decouple cors & docs from 1.3.0.
>>>>
>>>>
>>>>  I forgot a "not" obviously.. Sorry for that
>>>
>> Clarified via IRC:
>>
>> [21:00:26] <benoitc> well was just me trying to ask "do we really want to
>> ship at least without docs? "
>> [21:00:39] <benoitc> but i'm fine with both
>> [21:00:40] <+jan____> ah, I’d say yes.
>> [21:01:12] <benoitc> i wonder if we couldn't put the doc online for 1.3
>> at least
>> [21:01:39] <benoitc> since that part can be easily done
>> http://rcouch.org/docs/
>> [21:01:58] <+jan____> sure, why not, that’s completely unrelated to the
>> release
>> [21:02:18] <benoitc> indeed
>>
>> Cheers
>> Jan
>>
>
>

Re: Let’s ship 1.3.0 now.

["john.tiger" <jo...@gmail.com>]

this feels rushed - not a good thing with an enterprise thing like a db 
- does couch have big users that need the as is 1.3 features asap or 
even sponsors that are wanting to ship every 3 mos regardless ?  If not, 
why not wait and rally troops to make sure cors features are set, 
documentation is done, and some compiling issues are resolved - maybe 
the committee has other reasons, but 3 mos seems really quick for an 
enterprise thing like a db.

Others mlge may vary but we want to use the cors feature - could care 
less about a 1.3 without it



On 11/13/2012 01:08 PM, Jan Lehnardt wrote:
> On Nov 13, 2012, at 20:53 , Benoit Chesneau <bc...@gmail.com> wrote:
>
>> On Tue, Nov 13, 2012 at 8:51 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>
>>>> if it's part of 1.3.
>>> The point of this email is to decouple cors & docs from 1.3.0.
>>>
>>>
>> I forgot a "not" obviously.. Sorry for that
> Clarified via IRC:
>
> [21:00:26] <benoitc> well was just me trying to ask "do we really want to ship at least without docs? "
> [21:00:39] <benoitc> but i'm fine with both
> [21:00:40] <+jan____> ah, I’d say yes.
> [21:01:12] <benoitc> i wonder if we couldn't put the doc online for 1.3 at least
> [21:01:39] <benoitc> since that part can be easily done http://rcouch.org/docs/
> [21:01:58] <+jan____> sure, why not, that’s completely unrelated to the release
> [21:02:18] <benoitc> indeed
>
> Cheers
> Jan

Re: Let’s ship 1.3.0 now.

[Jan Lehnardt <ja...@apache.org>]

On Nov 13, 2012, at 20:53 , Benoit Chesneau <bc...@gmail.com> wrote:

> On Tue, Nov 13, 2012 at 8:51 PM, Jan Lehnardt <ja...@apache.org> wrote:
> 
>> 
>>> if it's part of 1.3.
>> 
>> The point of this email is to decouple cors & docs from 1.3.0.
>> 
>> 
> 
> I forgot a "not" obviously.. Sorry for that

Clarified via IRC:

[21:00:26] <benoitc> well was just me trying to ask "do we really want to ship at least without docs? "
[21:00:39] <benoitc> but i'm fine with both
[21:00:40] <+jan____> ah, I’d say yes.
[21:01:12] <benoitc> i wonder if we couldn't put the doc online for 1.3 at least
[21:01:39] <benoitc> since that part can be easily done http://rcouch.org/docs/
[21:01:58] <+jan____> sure, why not, that’s completely unrelated to the release
[21:02:18] <benoitc> indeed

Cheers
Jan
-- 

Re: Let’s ship 1.3.0 now.

[Benoit Chesneau <bc...@gmail.com>]

On Tue, Nov 13, 2012 at 8:51 PM, Jan Lehnardt <ja...@apache.org> wrote:

>
>> if it's part of 1.3.
>
> The point of this email is to decouple cors & docs from 1.3.0.
>
>

I forgot a "not" obviously.. Sorry for that

- benoît

Re: Let’s ship 1.3.0 now.

[Jan Lehnardt <ja...@apache.org>]

On Nov 13, 2012, at 20:43 , Benoit Chesneau <bc...@gmail.com> wrote:

> Why 60 days.

We roughly agreed on quarterly releases. To simplify, I use 90 days.
I’d say we want at least 30 days to get a release branch into shape
(ideally we shouldn’t need that, but I’ll leave this for the transition
phase).

> Why not "when it"s ready" and by it's I mean doc & cors.

The feature branches get into the release track whenever they are ready.

> if it's part of 1.3.

The point of this email is to decouple cors & docs from 1.3.0.

Cheers
Jan
-- 





> 
> - benoit
> 
> On Tue, Nov 13, 2012 at 8:28 PM, Jan Lehnardt <ja...@apache.org> 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
>> --
>> 
>> 

Re: Let’s ship 1.3.0 now.

[Benoit Chesneau <bc...@gmail.com>]

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 <ja...@apache.org> 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
> --
>
>

Re: Let’s ship 1.3.0 now.

[Robert Newson <rn...@apache.org>]

+1

As for "new", I think the new view engine counts. :)


On 13 November 2012 19:28, Jan Lehnardt <ja...@apache.org> 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
> --
>
>
>