Re: [Sbcl-devel] version numbers (was Re: I'm (sort of) back)

[<me...@re...>]

Daniel Herring <dhe...@te...> writes:

> On Mon, 3 Sep 2012, Christophe Rhodes wrote:
>
>> I am also tempted to mess with the version number scheme, because I find
>> 1.0.x as x tends to infinity slightly odd
>
>
> On Mon, 3 Sep 2012, Paul Nathan wrote:
>
>> As a user, I find 1.0.n, n -> inf fairly odd. :)
>>
>> One scheme that is used and may be a good fit is 'Semantic Versioning' http://semver.org/.
>
>
> That looks like a fairly good scheme.  It reminds me of libtool's scheme. 
> The key goals of signalling changes that require code modification, 
> changes that require recompilation, and changes that work transparently 
> are similar.

A long time ago, before git and its brothers came onto the scene and cvs
was the default, I had the pleasure to implement some support for
configuration management at a job. What came out of that effort was
ho-cvs [1] based on meta-cvs, a really ugly workaround for not having a
sane version control system. More importantly, coma [2] was born too.
The idea was very similar to what semver describes, and we used it for
versioning components of multiple products (and their slightly different
variants).

The solution was intended to help in reducing the merging overhead
between all the different products by eliminating the need to create
branches (only had to be considered for major (incompatible) changes),
and be able to answer validate the current configuration by rules on
versions and other configuration settings.

One extension over semver is that versions support a 'variant', a branch
name really. #v1.2.3 refers to version 1.2.3 on the main branch.
#vX:4.5.6 refers to version 4.5.6 on branch X.

The canonical representation of #vX:4.5.6 contain the branch off points
back to the main root of the version tree like #v0.3.1/A:3.2.2/X:4.5.6.
Two canonical versions can always be compared for compatibility.

The code that implements this is version.lisp (and test-version.lisp) in
the ho-cvs tarball [3].

My experience with tools relying on public API compatibility as
specified by the programmer is that it's not black or white: adding a
method to a java class is normally thought of as a minor (backwards
compatible) change, but it could very well break subclasses or code that
uses reflection. Also, most software has trouble defining a public API.

Note that ho-cvs is obsolete and coma, while it has good ideas, is
unmaintained.

Gabor

[1] http://quotenil.com/ho-cvs/
[2] http://quotenil.com/coma/
[3] http://quotenil.com/ho-cvs/download/hoc-0.1.4.tar.gz