couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <webmas...@nslater.org>
Subject Re: 1.0 Vote
Date Fri, 25 Jun 2010 19:35:20 GMT
I think we're in agreement?



On 25 Jun 2010, at 20:29, Jan Lehnardt <jan@apache.org> wrote:

> 
> On 25 Jun 2010, at 20:59, Noah Slater wrote:
> 
>> 
>> On 25 Jun 2010, at 19:48, Randall Leeds wrote:
>> 
>>> I've been under the impression that 0.11.x was somewhat of a 1.0RC and
>>> that's why there's been any discussion at all about branching 1.0 from
>>> it. If this is the case nothing should need to be backported after the
>>> 1.0 branch because there are no more 0.11.x releases, they are simply
>>> 1.0.x.
>> 
>> This is horribly broken.
>> 
>> /branches/0.11.x is for BUG FIXES for /tags/0.11.n
>> 
>> A user who is using 0.11.0 should be able to patch up bugs by upgrading to 0.11.n
without having to install 1.0. That is the whole purpose of this kind of versioning and release
procedure. Someone please tell me this is still going to be the case?
> 
> Yes, this is still the case.
> 
> 
>> J Chris:
>> 
>> What is happening to the 0.11.x branch after 0.1 is cut? Is it going to revert to
being a bug fixing branch for the exiting 0.11.n releases? If not, then something is horribly
horribly broken: either the plan for releasing 0.1, or my understanding of the plan.
>> 
>> I presume it is the latter, but could someone explain to me how I'm confused?
> 
> When we started discussing where 1.0 should be branched from we decided it should be
0.11.x assuming a pretty quick 1.0 after the 0.11.0 release. That didn't happen and we started
committing patches to 0.11.x that are not strictly bug fixes for 0.11.0 but necessary for
a sensible 1.0. Despite agreeing on that plan, some devs didn't backport some fixes from trunk
to 0.11.x creating the merge mess that I attempted to fix in at least two longer sessions
of getting 0.11.x into shape that it makes sense to be the base for a 1.0.0.
> 
> This is a divergence from the original release procedure, yet it was agreed upon here.
> 
> 
>>> The cleanest thing in my mind would be:
>>> 1) branch 1.0.x from trunk
>>> 2) revert any 1.1 junk on 1.0.x
>> 
>> Sounds good.
> 
> Close:
> 
> 1) branch 1.0.x from trunk.
> 2) revert non-bugfix changes from 0.11.x.
> 3) revert 1.1 patches (not junk at all) from the 1.0.x branch.
> 
> 
> 
>>> 3) abandon the 0.11.x branch and don't cut any further releases from it
>> 
>> The 0.11.x branch is there for releasing bug fixes for 0.11.n, so it will obviously
stay.
> 
> Correct, it will stay. On top of bug fixes, the branch is required to stay around for
potential future security issues.
> 
> Cheers
> Jan
> --
> 
> 
> 

Mime
View raw message