Faré wrote: > On Mon, Mar 24, 2014 at 6:30 PM, Faré <fah...@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
