[asdf-devel] What is the release process for ASDF?

[Robert Goldman]

Faré wrote:
> 2009/12/1 Robert Goldman <rpgoldman at sift.info>:
>> I just checked, and I see that my documentation patches have not been
>> pushed.  Any objection to pushing them before the release?
>>
>> If you are willing to do that, I'd appreciate it.  I prefer not to do
>> anything irrevocable to the git repo....
>>
> Sure. Those of you who have patches you want included in the next
> release, please re-send them to me, if possible based on my
> development repo at
>   http://common-lisp.net/project/xcvb/git/asdf.git

OK, I will resend.


> Note that now that we have an asdf.asd, I'd like to keep anything not
> necessary to bootstrap in separate systems -- though I could be
> convinced otherwise and will yield to majority opinion on anything
> regarding ASDF.
> 
> Actually, I'd even like to declare asdf:run-shell-command deprecated
> copy it somewhere else for those who'd officially like to use it. A
> cursory look at google/codesearch for "asdf:run-shell-program" finds
> cclan, asdf-install which are readily fixable, but also a few others,
> too. There might be some that are not indexed or import the symbol,
> though.

I would very much prefer that we not do this.

Removing asdf:run-shell-command will break existing asd systems.  I
have, for example, used asdf:run-shell-command as a portable means for
running perl scripts and make inside ASDF system definitions.  I don't
really think that google/codesearch is an adequate resource for
assessing the danger of such breakage.  It certainly would only reveal
O(1%) of my asdf system definitions, since many of my systems are not of
general interest, and are only of use in my company, in a small group, etc.

I would prefer a far more conservative approach to evolving ASDF, one
that emphasizes not breaking existing systems.

I'm also concerned that you have talked about pushing stuff to contribs,
but we don't yet have an announced plan for distributing such contribs.
Do they just come with ASDF, or are they separate downloads?  I could
possibly live with contribs that come in the distribution of ASDF, but
separate downloads would not be acceptable.  Indeed, we have just taken
a step in the other direction, rolling asdf-binary-locations into core ASDF.

Two other issues:

1. ASDF does not have a graceful way of loading extensions.  We have
just heard some complaints from Samium G about the way looking for a
system definition can cause source code loading.  This is forced upon
ASDF users by a limitation of the model.  There is no clean way for us
to say "this ASDF extension is required by this system definition."  All
we can do is put

(asdf:oos 'asdf:load-op <my-asdf-extension>)

in our .asd files....

So every time we move a core function out of asdf, not only do we break
existing systems, but we also make asdf less declarative and more
imperative.

2. Existing ASDF extensions get stuffed into the ASDF package.  This
seems like something that's likely eventually to cause us pain (as in
"name collisions" and "method definition collisions").

To do this gracefully, we must move in the direction of providing an
ASDF-extender API.  For example, a package like ASDF-INTERNALS that
exports a lot more of the ASDF symbols, and some more method combination
hacks, like the one that allows ASDF to have "around" methods inside
:around methods defined by ASDF users.

In my opinion, such a careful, graceful treatment of ASDF unbundling
would require more effort than we are likely to recoup in benefits.
Certainly, it's not where I'd like to put my open source hours (but if
others do, more power to you!).