On Thu, 2013-11-21 at 00:36 -0500, Daniel Herring wrote: [...] > FWIW, my little "read-macros" package demonstrated some functionality to > simplify writing read-time conditional code without pushing everything on > *features*. > > http://git.tentpost.com/?p=lisp/read-macros.git
Interesting. > Back on-topic, semantic versioning systems such as advocated by GNU > libtool try to provide a conservative estimate on portability. libtool combines the notions of API and ABI compatibility. We have it a bit easier. [...] > On Tue, 19 Nov 2013, Anton Vodonosov wrote: > > > But my point - it's not enough to just bump major > > version number, as semantic versioning suggests. > > > > If author of "somelib" library wants to make an API incompatible > > change, it is better to release new ASDF system "somelib2" > > and put code into new package somelib2. > > This concept resonates with me. The existence of a new API version should > not preclude further releases of older API versions. In practice nobody is going to take the time to maintain older versions except for a handful of very popular projects, and even in that case there will be significant social and economic pressure into avoiding divergence and waste of resources. [...] > Towards this end, I had started investigating a set of macros and/or > features to simplify the process of embedding version information directly > into the CL package names themselves. Unfortunately, I didn't find any > clean solution that met my goals. Here are a couple emails on the > subject. > > http://article.gmane.org/gmane.lisp.libcl.devel/110 > http://article.gmane.org/gmane.lisp.libcl.devel/123 > [Note: LibCL and its mailing lists are now defunct.] Some interesting ideas there. [...] > All that said, semantic versioning is tried and true, easy to implement, > and a useful improvement on the current ASDF status quo. Other approaches > such as behavior testing and nonlinear are harder to implement and should > play nicely with a semantic versioning system. Thus I am all in favor > with ASDF adopting a reasonable semantic system today. I agree. > Whatever we do, please implement an escape hatch for the end user to > override the versioning system's idea of compatibility. These things > often have obscure failure modes and/or prevent nuanced usage. Just like > CL::internal symbols, it is nice to have a straightforward way to void the > warranty and bypass the normal safety mechanisms. I agree. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.
signature.asc
Description: This is a digitally signed message part
