[Rubygems-developers] Versioning policy input

Eivind Eklund eivind at FreeBSD.org
Tue Apr 6 13:36:44 EDT 2004


On Mon, Apr 05, 2004 at 10:30:21PM -0400, Chad Fowler wrote:
> >Please take a look at the attached patches, which contain a
> >straightforward implementation of the proposed internal versioning 
> >scheme
> >B (i.e. the complete, x.y.z one).
> >
> 
> Do you prefer B over A for some specific reason?   I'm not sure I like 
> either yet, but if it were up to me right now and I had to pick one of 
> them, it would be A.

Background (I don't know if this is immediately obvious or not):

Format A (single digit version number X) has the following properties:

A bump of X is essentially a rename of the library.  A library/version
number consumer cannot assume *anything* about libraries between version
numbers.  If the library with the correct version number isn't
available, the application cannot be assumed to run.

If no further revisioning is available, X tends to increase fairly fast,
as it needs to be increased every time somebody add an API to a library.
An application author can theoretically test and find out what the
lowest version number his app works with is and require that, but that
requires that each application author test against all versions of the
library.  The application can NOT be used with any higher version of the
library (safely), as each version number change is a complete API change
- can be addition, can be deletion, can be plain change.


Format B (X.Y.Z version number) has the following properties (I'll use
X.Y.Z to indicate library version number, and x.y.z to indicate version
required by the library consumer):

An update of X indicates a different[1] API - no guarantees
given.  A consumer requires X == x in order to "guarantee" working.

An update of Y indicates an extended[2] API.  A consumer requires
Y >= y in order to "guarantee" working.

An update of Z indicate that the library has been updated in a
compatible fashion.  A consumer sets no requirements on Z, but higher Z
is always better.  This can be speed improvements, memory usage
improvements, bug fixes for rare enough cases that it should not be
counted against apps, etc.


Eivind.

[1] Formally: An X bump indicates that preconditions are tightened or
    postconditions losened.

[2] Formally: An Y bump indicates that preconditions are loosened or
    postconditions tightened.


More information about the Rubygems-developers mailing list