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*.
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.