>>: 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. Regards, —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Any sufficiently advanced incompetence is indistinguishable from malice.
