How would you feel...

[Faré]

On Tue, May 26, 2015 at 2:55 PM, Robert P. Goldman <rpgoldman at 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