On 1 February 2010 10:18, Robert Goldman <[email protected]> wrote: > On 2/1/10 Feb 1 -12:59 AM, Tobias C. Rittweiler wrote: >> 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. Yes. When we've got the configuration and upgrade story together, we'll do a first round of glaring bug fix and push a 1.900 to the vendors.
> 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. Starting with asdf 1.900 we'd push :asdf2 in the features. >From then on, asdf:*asdf-version* will be guaranteed to exist. > 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? #+asdf2 > :asdf-test-op-load-op-depend No, too complex, I'd say. > 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. For 2.5, 2.6, etc., use a check on asdf:*asdf-version*, I'd say. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] May your desire to be correct overcome your desire to have been correct (which you were not, anyway). — Faré _______________________________________________ asdf-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
