kfogel@collab.net wrote:
>>>http://apr.apache.org/versioning.html are maybe a bit too strict?
Those rules are actually for a very different beast: APR is a collection of
_library_ routines, not an application. Libraries are, by their very nature, a
slow moving target. So trying to force one versioning model on a very different
type of program is likely to cause some conceptional problems.
> The current release number system forces us to use major version
> increments for API changes. Unfortunately, the world at large assumes
> that a major version increment also means major new functionality. In
> other words, we have no way to introduce an API change without also
> either introducing major new features, or disappointing users who
> expect "more" from a 2.0.
Strongly agree.
>
> It seems to me like we have four concepts conflated in three numbers:
>
> a. Major feature additions
> b. API changes
> c. Changes that break binary compat
> d. Changes that maintain binary compat.
>
> Currently, (a) and (b) live in one number, the major version, and the
> others have their own numbers. My reshuffling gives (a) and (b) each
> their own number, and puts (c) and (d) in one number, the patch
> level.
I like this idea a lot, except that it limits conflates two contradictory
concepts into a single slot. I think it is also one reason why the even odd
model works better for this.
For "release" versions, the third tuple denotes binary compatible changes only.
For "developer" versions, the third tuple might include incompatible binary
changes (or it might not). The assumption is that between one "release" and
another (even number change), the API is bound to change at least somewhat.
The development stream proceeds pretty much at the pace that the current pre-1.0
stream has gone; the compatibility promise is only limited to 1 version (by
which we now refer to the third tuple). The release stream is always limited to
compatible changes.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 9 04:43:47 2004