On 1 February 2010 10:18, Robert Goldman rpgoldman@sift.info 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é