[asdf-devel] Releasing asdf 3.1.1 ?

[Robert P. Goldman]

Faré wrote:
> I'm re-running all the tests with ASDF 3.1.0.35. Looking good so far.
> Please keep testing in view of a release 3.1.1.

I'm interested in a release relatively soon, but I'm not in a rush.

While there are bug fixes waiting to reach our users, I'm quite
concerned by the loss of backwards compatibility in systems that defined
their own OPERATION subclasses.

As far as I can tell, *all* such systems will break, since the old
solution was to subclass OPERATION and the new solution is to subclass
DOWNWARD-OPERATION to achieve the same results.  *ALL* programmers'
locally-defined operation subclasses are now broken by this change.

I have personally seen multiple systems that are broken by this change,
and I would like to see some hard thought put into repairing this.

A somewhat drastic solution would be to make the name OPERATION now
denote DOWNWARD-OPERATION (which would remain as a canonical name), and
rename the common superclass of DOWNWARD-OPERATION and UPWARD-OPERATION
to something like ABSTRACT-OPERATION or COMMON-OPERATION.

The current refactoring is quite problematic, since it moves some of the
previously-existing characteristics of OPERATION out and into a
sub-class that no one has ever heard of before.

Unfortunately, the above solution is not ready for prime-time, either,
since if we add COMMON-OPERATION, all programmers' methods that dispatch
on OPERATION will break if used with PREPARE-OP.  On the one hand,
that's probably not a big deal, since no one will have been customizing
UPWARD-OPERATIONs, since they haven't existed.  On the other hand,
programmers who want to write extensions that really are generic to
*all* types of operation (e.g., EXPLAIN type methods) would be broken by
this proposed repair.

This problem also exposes a HUGE hole in our regression-testing methods:
we have nothing that tests extensions to the ASDF protocol.

I also find that OUTPUT-FILES may now be called more eagerly than
before, perhaps because of the new PREPARE-OP.  I have seen systems
(perhaps not well-built systems....) that defined OUTPUT-FILES on an
operation, O, in a way that assumed that earlier operations (COMPILE-OP
and LOAD-OP) would be called before the OUTPUT-FILES method on O.  That
actually seems wrong, since OUTPUT-FILES is part of the plan-making part
of the ASDF protocol, rather than the plan-execution part, but it *used
to work* and given the extremely sketchy information available to users
who wish to customize ASDF, such disruptions need to be very gently handled.

Finally, as the responsible party now, I'm not comfortable sending out
another release until I have come to understand the new protocol better
than I do now.  Indeed, it was culpably negligent of me to release the
last couple of versions, and I apologize for doing so.