[Mono-dev] [Ximian-mono-list] Planning: Mono version numbers.

[Marek Habersack]

On Fri, 11 May 2007 21:46:07 +0200, Massimiliano Mantione <massi at ximian.com>
scribbled:

> 
> On Fri, 2007-05-11 at 14:13 -0400, Miguel de Icaza wrote:
> > [...]
> >     So what we need is to come up with a new release number scheme for
> > the above.   
> 
> Just my 2c, and it might look really gross...
> 
> Calling versions "major.minor", I'd do the following:
> - Increment "major" at release "C" (compacting GC and API changes),
>   especially because of the API changes.
> - Increment "minor" for every other release, number assigned with
>   a "first come, first served" policy between the releases :-)
> Trying to assign numbers now, before we know what will be ready
> first, is inappropriate IMHO.
> 
> Since it's *likely* that A and B will become ready before the rest,
> this *could* mean:
> - "1.4" => Mono A
> - "1.5" => Mono B
> - "2.0" => Mono C
> - "2.1" => Mono "whatever comes next"...
> But if the order in which things get ready changes, this scheme
> changes accordingly.
It's not that bad, your scheme :). Personally, I like the way the dynamic
libraries on *nix are done. They consist of three parts:

ABI_VERSION.INTERFACE_VERSION.RELEASE_NUMBER

We increase the first if we break the ABI (either the runtime or the class
libraries, or introduce any other breaking changes in the toolchain etc.). We
increase the second one if we add new class libraries/methods without breaking
the ABI. The third is increased every time we do a release that's netiher #1 or
#2 above. Of course, it can lead to version numbers like 2.1.12314, but the
version part increase rules can be defined a bit differently to what I outlined
above. The idea is that each part of the release version should have a real and
clearly defined meaning.

marek