On Tue, May 26, 2015 at 2:55 PM, Robert P. Goldman rpgoldman@sift.net wrote:
Faré wrote:
Oh well, I'm torn. I think it's a good thing, but maybe incompatible enough that we should release 3.1.5 now and start a 3.2.0 branch.
I don't think this counts as incompatible, since it would only be a STYLE-WARNING (so not break anything).
At ITA we used to consider any uncaught STYLE-WARNING at breaking the build, which allowed us to keep our codebase clean and not drown useful warnings in a sea of noisy messages. I suppose other CL shops might do as well. Of course, they could "just" patch their dependencies to hush this warning, as we would have done.
I'm concerned about postponing this because I don't see implementations -- *especially* the commercial ones -- picking up ASDF revisions quickly.
I'm not sure how postponing will make implementations pick ASDF up faster. The frustration about that next feature not going to make it to implementations nearly as fast as you'd like is going to be with you no matter what. Count one year for adoption by "early adopters", and two years for ubiquitous adoption. That was the approximate delay for both ASDF 2 and ASDF 3. Delaying a release by a few weeks doesn't make sense in contrast.
So I view ASDF releases as a very finite resource, and one where we have to get the most bang for the buck.
That's probably true to a point for major releases (e.g. if you wanted to make a milestone release 3.2), but minor releases seem to not be as much of a hassle. That's why I believe a safe plan is to release 3.1.5 now and indeed wait a bit for a 3.2 release, after we merge the more "experimental" code.
I'd rather postpone than push a release out the door, and maybe find it's the only one that the implementations will bundle for this year.
Once you accept that vendors don't care about your schedule and work by their own, your life becomes less stressful. The big hard pushes were for ASDF 2 then ASDF 3, where it was important that every implementation should provide the new major release for compatibility reasons. To a lesser degree it would be nice if everyone could rely on ASDF 3.1 (and we should hopefully be there next year), but now that ASDF 3 has auto-upgrades that work without kinks (as opposed to ASDF 2 where they worked but only if the user exercised extra caution at startup or ASDF 1 where they didn't work at all), users unhappy about their implementation's release schedule can easily install an upgrade and forget about it.
That said, it'd be nice if the following implementations upgraded more often: Allegro, CLISP, ECL, SBCL. The former two haven't reached ASDF 3.1 yet.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Always design a thing by considering it in its next larger context — a chair in a room, a room in a house, a house in an environment, an environment in a city plan. — Eliel Saarinen