How would you feel...

[Robert P. Goldman]

Faré wrote:
> 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.

We do this for our Jenkins CI jobs, too.  I suppose I might change that
policy for systems we depend on, as opposed to systems we build.

OTOH, it's probably A Bad Thing if you depend on a system for something
you are doing, and don't know what license it uses.

But that's why I created a special class of CONDITION for this case --
so you can muffle it if you don't care.  It would be nice if there was
some way to detect the distinction between internal systems (fix them!)
and external systems (muffle).

I'll push my topic branch today.  It needs a test script, and I'd like
to make it skip signaling on "slashy" subordinate systems, but I'd love
comments in the meantime.

> 
>> 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.

I figure it's rate limited, not time limited.  I.e., I get a limited
number of opportunities to have the implementations pick up an ASDF, so
I'd like to pack in as many fixes and enhancements as possible.

> 
>> 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.

My copy of Allegro is at 3.1.4.3.  They have issued at least two ASDF
patches since the 9.0 release.

clisp seems to have given up releasing.

I'm excited to see ECL get revitalized now that it has new maintainers.

My SBCL is at 3.1.3.  I think 3.1.4 is solid enough that it should be
updated there.