You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Noah Slater <ns...@apache.org> on 2008/12/29 11:48:41 UTC

Re: Changing rev to _rev in view results (Was: Re: newbie question #1)

On Mon, Dec 29, 2008 at 09:11:29PM +1030, Antony Blakey wrote:
>
> On 29/12/2008, at 7:20 PM, Christopher Lenz wrote:
>
>> This would break all substantial client code out there for
>> questionable benefit.
>
> It's not even a released product yet. Preserving accidental
> implementation artifacts to satisfy early pre-release clients is a very
> sad idea.

Come again? CouchDB is most certainly a released product.

I understand the concepts about being able to break backwards incompatibility
before the legendary 1.0 release of a free software project, but categorically
denying there is nothing to consider is wildly misleading!

-- 
Noah Slater, http://tumbolia.org/nslater

Re: Changing rev to _rev in view results (Was: Re: newbie question #1)

Posted by Jan Lehnardt <ja...@apache.org>.
On 29 Dec 2008, at 11:48, Noah Slater wrote:

> On Mon, Dec 29, 2008 at 09:11:29PM +1030, Antony Blakey wrote:
>>
>> On 29/12/2008, at 7:20 PM, Christopher Lenz wrote:
>>
>>> This would break all substantial client code out there for
>>> questionable benefit.
>>
>> It's not even a released product yet. Preserving accidental
>> implementation artifacts to satisfy early pre-release clients is a  
>> very
>> sad idea.
>
> Come again? CouchDB is most certainly a released product.
>
> I understand the concepts about being able to break backwards  
> incompatibility
> before the legendary 1.0 release of a free software project, but  
> categorically
> denying there is nothing to consider is wildly misleading!

We've been very clear in the past that we might break the API before  
1.0 (which
Damien narrowed down to 0.9 now, which is okay). I'm not categorically  
denying
that there's client code out there, but we document the changes well  
and the
changes required should be minimal and easy to do.

At this stage, client code should not be a concern here.

Cheers
Jan
--

Re: Changing rev to _rev in view results (Was: Re: newbie question #1)

Posted by Noah Slater <ns...@apache.org>.
On Mon, Dec 29, 2008 at 09:47:36PM +1030, Antony Blakey wrote:
>
> On 29/12/2008, at 9:18 PM, Noah Slater wrote:
>
>> I understand the concepts about being able to break backwards
>> incompatibility
>> before the legendary 1.0 release of a free software project, but
>> categorically
>> denying there is nothing to consider is wildly misleading!
>
> I think a 1.0 release is not especially significant to free software
> projects compared to non-free projects.
>
> Even with commercial software and internal releases there are issues
> related to change management and consequent costs of compatibility
> breaking, so I don't think there's nothing to consider, but Christopher
> was commenting about 'substantial client code out there', which to me
> sounds like an argument I believe is only significant for 'released'
> versions. Without some distinction between 'released' and
> 'no-guarantees-work-in-progress', you can't experiment with changes.

I'm not sure I see your point. CouchDB has a whole truck load of third party
clients and community code that would all instantly break. That's not to say we
shouldn't do it, but we should certainly consider the consequences.

-- 
Noah Slater, http://tumbolia.org/nslater

Re: Changing rev to _rev in view results (Was: Re: newbie question #1)

Posted by Antony Blakey <an...@gmail.com>.
On 29/12/2008, at 9:18 PM, Noah Slater wrote:

> I understand the concepts about being able to break backwards  
> incompatibility
> before the legendary 1.0 release of a free software project, but  
> categorically
> denying there is nothing to consider is wildly misleading!

I think a 1.0 release is not especially significant to free software  
projects compared to non-free projects.

Even with commercial software and internal releases there are issues  
related to change management and consequent costs of compatibility  
breaking, so I don't think there's nothing to consider, but  
Christopher was commenting about 'substantial client code out there',  
which to me sounds like an argument I believe is only significant for  
'released' versions. Without some distinction between 'released' and  
'no-guarantees-work-in-progress', you can't experiment with changes.

Surely 1.0 means something - I assert that there are very strong  
expectations about backwards compatibility within major point  
releases, and the pre/post-1.0 transition is very significant in that  
respect.

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Some defeats are instalments to victory.
   -- Jacob Riis