[asdf-devel] Branches to merge (I hope)

Faré fahree at gmail.com
Mon Mar 24 22:30:17 UTC 2014

>>: Faré
>: Robert

>> please consider merging these two branches before release:
>> * renamed-bundle-op, fixes https://bugs.launchpad.net/asdf/+bug/1294018
> I'm a little uncomfortable with this, simply because I don't use the
> bundle operations, so I worry that I might be letting someone else in
> for trouble (although I don't see how).
> Well, that's what pre-releases are for.  How about you merge that, and
> then we can try to make a strong push for testing.  I would guess that
> only people who are very involved with ASDF would use these operations
> so, as you say, changes should have minimal impact and be relatively
> easily identified.
OK. I merged that branch, together with corresponding backfixes
from my fare-3.1 branch.

This is a low-impact change, since I leave backward-compatibility stubs
under the old names. People should only be affected if they defined
they own methods on fasl-op or load-fasl-op, which I don't imagine
anyone doing (and indeed isn't done in Quicklisp).

>> * build-op, fixes https://bugs.launchpad.net/asdf/+bug/1293292
> This one I would rather postpone until after the next release.  Getting
> it into use would require even MORE modifications to the manual, and
> manual updates are already delaying everything.
> The need for a short name isn't enough of a requirement to cause us to
> eagerly change the main entry point into ASDF loading.
I'd like to convince you to let me merge in the branch anyway,
for the following reasons:

* The ability to designate operations with strings is good,
  and makes defsystem-depends-on more useful, even without make
* This is new functionality that doesn't interfere with anything,
  and therefore isn't a backward compatibility issue;
  then we can use #+asdf3.1 to depend on it.
  On the other hand, if we merge it after, we'll have to wait for
  #+asdf3.2 or so.
* You don't actually have to modify the manual now
  (and/or I can do the update),
  much less make it the "main entry point" into ASDF loading
  (I'm backing away from that claim).
  But I would like the functionality in to be able to rely on it
  being present.


—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Any sufficiently advanced incompetence is indistinguishable from malice.

More information about the asdf-devel mailing list