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

[Robert P. Goldman]

Faré wrote:
> On Mon, Mar 24, 2014 at 6:30 PM, Faré <fahree at gmail.com> wrote:
>>>> * 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.
>>
> branch build-op looks like it passes all tests, and in addition to the above,
> includes a refactoring of bundle.lisp to merge ecl and mkcl support
> and have mkcl follow the same image-op and program-op semantics as
> other implementations.
> I'd say it is ready to merge.

Your strategy seems reasonable.  How about we put into the manual a
chapter, towards the end (an appendix, perhaps?) describing the
EXPERIMENTAL build-op support, thus putting our users on alert that we
reserve the right to change BUILD-OP in ways that break their code.

I don't want there to be a premature lock-in here.

thanks,
r