[asdf-devel] Branches to merge (I hope)
Robert P. Goldman
rpgoldman at sift.info
Tue Mar 25 13:47:09 UTC 2014
> 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.
More information about the asdf-devel