On 2/1/10 Feb 1 -12:59 AM, Tobias C. Rittweiler wrote:
Faré fahree@gmail.com writes:
I've just released ASDF 1.501 in the official repository, now with all the source registry configuration that I previously discussed. It's currently documented in its own file README.source-registry, rather than in the general manual asdf.texinfo, as it should be. Patch welcome.
Note that I bumped the version from 1.375 to 1.500 then 1.501. This to indicate that we're not using CVS anymore, that I've reached a milestone towards my goal of an "ASDF 2" that I could push as a replacement to ASDF. It passes the tests with SBCL. But the tests could be extended to do more.
Before bumping to 2.0 directly, I'd suggest to go through at least one phase of release candidate. The release candidate is pushed to vendors (hopefully they will adopt even though it's called release candidate), the difference is that all newly introduced APIs are marked as "Experimental" until the actual 2.0 release. So the API is time-tested for a few months.
The thing I would most like to see before the release of ASDF 2.0 is closure on the question of how to achieve backwards compatibility.
Let's say that I want to provide a library with an ASDF system definition that will work on both "Classic" ASDF and ASDF 2.0. How do I do this?
Should we add
:asdf2
to *features*?
Or should we add more special features to indicate particular new capabilities, such as
:asdf-test-op-load-op-depend
so that I can do something like
:in-order-to ( #-asdf-test-op-load-op-depend (test-op load-op))
?
One approach would be to use asdf:*asdf-revision*, but since this is not present in Classic ASDF, the idiom would become cumbersome:
(if (boundp (intern (symbol-name '#:*asdf-revision*) :asdf) .... ....)
yucky...
Of these, I think I favor the :asdf2, but I fear it, because it means we'll end up with :asdf2.5, :asdf2.6, ... etc. But that may be the best we can come up with.
cheers, r