couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@tumbolia.org>
Subject Re: 1.0 Vote
Date Fri, 25 Jun 2010 18:04:33 GMT
Okay, sure.

On 25 Jun 2010, at 18:58, J Chris Anderson wrote:

> 
> On Jun 25, 2010, at 10:46 AM, Noah Slater wrote:
> 
>> On 25 Jun 2010, at 18:36, Jan Lehnardt wrote:
>> 
>>> I don't care much either way about where to cut 1.0 from at this point except
I wish this would have been brought up earlier so I didn't had to waste a lot of time on the
backports.
>> 
>> I do.
>> 
>> When we set out our release procedure, we said that we could cut all new versions
from trunk. We copy trunk to a branch folder, and release from that into tags. Bug fixes are
back-ported to the branches and then cut to a new tag.
>> 
> 
> I agree with you Noah, that we should cut new versions from trunk (in general).
> 
> A few months ago we discussed a plan whereby 1.0 would be cut from 0.11.x. The idea behind
this was to make sure no one sat on code that would be good for 1.1 but not 1.0. Eg: feel
free to commit crazy stuff to trunk, as long as you don't backport to 0.11.x, it won't be
in 1.0.
> 
> However, it turned out that trunk hasn't seen much action that we should leave out of
1.0, so I'm happy to stick to our normal release procedure here, and cut from 1.0 from trunk.
I know others disagree with me and think we should stick to our stated plan of cutting it
from 0.11.x
> 
> I don't actually care what we branch from. I'm also not bothered by the idea of doing
differently than we planned.
> 
> What matters is that 1.0 have the same code as trunk (minus whatever commits need holding
back for 1.1).
> 
> (apologies if this got sent twice... bah, mail clients)
> 
>> I'm really not up to speed with what is going on at the moment, but I must say that
I find whatever it is quite confusing. It is my uneducated preference that we stick to the
release procedure as it is documented.
>> 
>> If the release procedure is defective in some way, then I propose we update it to
fix whatever process bug we found that has caused us to do whatever it is that we're doing
at the moment. I'm just really not happy with procedure deviating from what is documented.
It makes my job harder, for a start.
> 


Mime
View raw message