[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: version numbering and release lines

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2004-01-29 19:28:19 CET

--On Wednesday, January 28, 2004 3:04 PM -0500 Greg Hudson <ghudson@MIT.EDU>
wrote:

> I'm fine with this plan, but have two notes about some of its peripheral
> features.

Agreed.

> On Tue, 2004-01-27 at 19:34, kfogel@collab.net wrote:
>> There is one aspect of Subversion not addressed by the APR guidelines:
>> client/server compatibility.
>
> Also working-copy compatibility and FS compatibility.

+1. (And, I'd like us to explicitly document that, too.)

>> So the patch levels in the 1.0.x line would be, in order, 1.0.1,
>> 1.0.2, 1.0.3, etc. The API-but-not-ABI-compatible releases in the 1.x
>> line would be 1.2.0, 1.3.0, 1.4.0, etc.
>
> I think you misread the APR versioning guidelines. 1.1.0 does not get
> to break the 1.0 ABI. That has to wait for 2.0 just like an
> incompatible API change has to wait.
>
> What 1.1.0 gets to do is add functionality, such that a *downgrade* from
> 1.1.x to 1.0.x might be traumatic in terms of API or ABI compatibility
> or other issues. (A downgrade from 1.0.2 to 1.0.1 should not be
> traumatic except insofar as it will re-introduce all the bugs we fixed
> in 1.0.2.)

Right. I think Karl might say that we should punt this, but I dunno.

Case in point was reworking svn_client_blame to take a new argument. What
should we do? Does adding svn_client_blame2 make sense in 1.1, or should we
just break our ABI by changing svn_client_blame's signature in 1.1?

I think if we answer that, we're pretty much agreed on everything. -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 29 19:28:39 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.