[asdf-devel] version numbers

[Robert Goldman]

Daniel Herring wrote:
> ASDF has a poorly-defined versioning system.
> 
> I thought the following link may be of general interest.
> http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/
> 
> There sure are many ways to mess this up.  I'm not convinced there are any 
> ways to not mess it up.
> 
> Related links
> http://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html
> http://stackoverflow.com/questions/663209/can-someone-explain-about-linux-library-naming
> http://www.linux.com/archive/feature/45507?theme=print
> 
> 
> 
> Given the way ASDF is used today and the rapidly changing ABI of many CL 
> implementations, binary compatibility is a nonexistant issue.  Today's CL 
> cares rather about compile-time compatibility.
> 
> Either way, I almost think the correct solution is to say
> - each library release will have a unique version number
> - each library release will have a list of old version numbers for which 
> it is upwards compatible
> - each dependent library or application will list which versions it was 
> developed for
> - the "linker" (require or asdf) selects the newest version compatible 
> with the version specified by the dependent
> 
> This is similar to the libtool scheme, but using general data structures 
> rather than trying to encode everything into the filename.  How would asdf 
> respond to two files named X.asd?  It doesn't scan all such files looking 
> for the most recent version, does it?

My general impressions:

1.  The current versioning scheme doesn't work that well.

2.  But it's simple.

3.  Most people don't use the capabilities offered by the current
scheme.  I don't see the value of expending energy to provide a more
complicated and featureful versioning scheme given how little people use
the existing one.  That is while in the abstract I may agree with your
correct solution, it is completely unenforceable.

4.  Whatever we do, we should not change the syntax of version
specifications from the existing x.y.z(...) scheme to some cockamamie
way of packing into big decimal numbers the way they did for perl.
Reading that first blog post I was left wondering "why would you /ever/
do that?"

5.  We /could/ modify the ASDF search so that it looks for > 1 copy of
the library, but I think this is likely to be largely a waste of time.
Why is that?  Because even if ASDF /could/ handle loading an old version
1.x of library L for benefit of library A, what happens when library B
comes along and /it/ expects the latest and greatest version of L?  Even
if we can find two versions of L, we can't have two versions share the
same lisp image.  Anyway, I'd go at least 5-1 odds that library B will
just say that it wants L, and expect /implicitly/ that it will get the
latest version of L.  Library B's author is unlikely to have written
down that s/he expects version 2 of L.  The current versioning scheme,
where (:version L "2") will fail if L's author releases 3.0.0 also may
discourage version specifications.

5.1.  related to the above, maybe we should treat "component is later
than required" and "component is older than required" differently.  I'd
be inclined to treat the former as a CONTINUABLE error and only the
latter as a failure.  That allows us to proceed with hopes that a new
version will be compatible enough.  This would require a little surgery,
but only a little and might be worth doing.