[asdf-devel] ASDF git releases and ASDF "real" releases

[Robert Goldman]

Juan Jose Garcia-Ripoll wrote:
> Now that this discussion is opened, I would like to add a small
> question and a petition.
> 
> First the question. What is the level of integration of ASDF with
> different implementations? Does ASDF support all lisp implementations
> equally? Does SBCL (and perhaps other) ship the latest versions of
> ASDF?

This is a good question.  Do we have a notion of an ASDF release from
git that is flagged as worth packaging into an implementation?

I'm thinking that, for example, it's a good idea for us to be able to
push releases like 1.359 and 1.360 that people can try out and load on
their own.

But I'd argue that we should additionally take some action (I'm not sure
what this would be or how to manage it) to "bless" a release as being
stable enough for implementation maintainers to adopt.

At the very least, we might want to buff the tests, and have some page
where people could report testing ASDF on different implementation X OS
X architecture tuples.

Also, would it be worth tweaking the version numbering scheme to provide
information about the nature of the changes (as, e.g., ASDF itself
suggests).

For example, if we were at 1.0.359, my doc string patch, because it
wouldn't change the API or behavior, would just push us to 1.0.360.

The proposed test-op modification so that test-op is made to depend by
default on load-op would change behavior but not the API.  So this
should push us from 1.0.359 to 1.1.0. [Previously, test-op had no
default dependencies, and everyone wanting to implement it had to add a
:depends-on (:test-op (:load-op "foo")) to his/her foo system.]

Finally, if we were to change the API incompatibly, that should bump us
from 1.0.359 to 2.0.0.

[While this seems crispy and clear, I suspect that in practice "change
the API incompatibly" is not sufficiently operational that one could
take a look at a change and decide unambiguously if it was an
incompatible API modification.]

The ASDF development community has a higher duty to its users than
developers of a less pervasive library, so it's probably worth thinking
about this a little to get it right.

Best,
Robert