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. _______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
