couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J Chris Anderson <>
Subject Re: 1.0 Vote
Date Fri, 25 Jun 2010 17:23:40 GMT
I'm a little confused.

Last week I mentioned that we should cut trunk from 1.0, after reviewing the diff between
0.11.x and trunk, and seeing that every change in trunk I could be confident is release quality.

Now we've done a bunch of backporting to 0.11.x, which is bringing it closer to trunk, but
not close enough, imho.

We could continue to backport to 0.11.x until `git diff trunk 0.11.x` is empty, but that seems
like crazy lots of work to no good end.

Are there any patches in trunk which do not belong in 1.0?

Jan mentioned that Adam has some writer patches that he wants in 1.1. Is there anything else?

I would *definitely* like to backport the couch_util:get_value patch. There's no reason to
have that huge diff between 1.0 and 1.1 (that doesn't change functionality). The big diff
just makes it harder to maintain 1.0 going forward.

I don't care which route we get there by, but at this point, there is lot of code in trunk
that belongs in 1.0

It might be simpler to branch trunk, and remove the one or two commits that shouldn't be in
1.0, than to play the rebase game even longer, trying to get 0.11.x to look like trunk.

Can you help me identify the commits that should *not* be in 1.0? 



On Jun 25, 2010, at 8:35 AM, Filipe David Manana wrote:

> On my GNU/Linux machine, branch 0.11.x, I have the test list_views.js with
> an assertion failing:
> Assertion failed: expected '{"total_rows":10,"offset":0,"update_seq":11}',
> got '{"total_rows":10,"offset":0}
> On Fri, Jun 25, 2010 at 1:30 PM, Noah Slater <> wrote:
>> Where are we on Windows support?
>> The last time I heard, the unofficial Windows binaries that can be built at
>> the moment are not ready for the prime time. Is this still the case. If
>> we're doing a windows release, who is going to prepare the release artefact?
>> On 25 Jun 2010, at 01:20, Damien Katz wrote:
>>> It looks like the file deletion issue may be already fixed windows. If we
>> can get confirmation the Windows compaction and deletion problems are fixed,
>> I think we can prepare a release artifact to vote on.
>>> -Damien
>>> On Jun 24, 2010, at 12:24 PM, Jan Lehnardt wrote:
>>>> On 24 Jun 2010, at 01:22, Damien Katz wrote:
>>>>> On Jun 23, 2010, at 4:15 PM, Paul Davis wrote:
>>>>>> On Wed, Jun 23, 2010 at 6:47 PM, Damien Katz <>
>> wrote:
>>>>>>> I think we are really close to being ready for 1.0.
>>>>>>> Are there any issues/patches that need to be handled before we
make a
>> release and vote on it?
>>>>>>> Noah, do you have any issues, and can you make the branch and
>> candidate?
>>>>>>> One thing I can think of is windows file support, so that compaction
>> and deletion work properly. There exists a fix for it from Mark Hammond, but
>> we need a patched Erlang VM before the fix can work. The upcoming R14B
>> includes the VM patch, but I think we should wait until it's actually
>> released before we include Mark's fix.
>>>>>>> -Damien
>>>>>> If you mean the SHARED_DELETE thing for opening files, that was
>>>>>> included in R14A which was released the other day.
>>>>> I do mean the SHARED_DELETE thing, and I didn't know that. Great news!
>>>>> Anyone up for merging the patch and testing on windows?
>>>>> Patch is here:
>>>> The patch is stale, we'd need somebody to get it applying to trunk.
>> Anyone?
>>>> Cheers
>>>> Jan
>>>> --
> -- 
> Filipe David Manana,
> /
> "Reasonable men adapt themselves to the world.
> Unreasonable men adapt the world to themselves.
> That's why all progress depends on unreasonable men."

View raw message