How would you feel...

[Faré]

>> You are changing the third number, which will look like a patch to a
>> minor revision. They probably wont bother with updating (if it's any
>> amount of work) unless they see 3.2 or 4.0 is my guess. That's how I
>> would think.
>
> Actually, if I was them, I wouldn't bother updating until I saw 3.2.1! ;-)
>
Well, our stable releases used to be two-digits versus three-digits
for the unstable ones; these days it's three digits for the stable
releases vs four-digits for development patches.

The who point of stable releases is that we can tell the world: these
versions have received extensive testing and can be vouched for,
whereas these don't.

Which makes me feel queasy about some implementations delivering
development versions of ASDF (e.g. Allegro delivering 3.0.2.3 or
3.1.4.3, or CLISP being stuck at 3.0.2.26). It's fine if there's a bug
that affects their implementation and is fixed at that patch level
*and* they promptly upgrade to the next stable release. But making
lingering for months or years on such unsupported intermediate version
is poor practice.

ccl is always prompt at updating (thanks, rme). cmucl, abcl do it as
part of their release cycle. So does lispworks, except it releases
only every so many years. sbcl and ecl are lagging a bit (a lot these
days), but generally not doing too bad. mkcl is lagging a lot. gcl
doesn't reply to my bug reports. mocl, scl, xcl are dead. clasp is
newborn.


> But seriously, waiting until the first bugfixes show up doesn't work
> well unless *somebody* runs the initial release and tests it in actual
> day-to-day use.
>
I always use the latest asdf, but the range of things I use day to day
is limited. At least, the basic functionality,
package-inferred-system, run-program and image dumping are kept in
working order (plus cffi extensions, that I rely on).

> It would be nice to figure out a way that ASDF could work nicely with
> the implementations so that implementors have an easy option to use the
> latest ASDF patch version day-to-day and see how well it plays with the
> latest version of the CL implementation.
>
As long as implementations offer ASDF 3, it's trivial to install asdf
in your source-registry and let it upgrade itself. And now, all
implementations do, at least all those that are maintained except gcl.
All but clisp (and maybe allegro express) provide 3.1, so your
source-registry now automatically includes ~/common-lisp/ so that's
all even easier. If you want to test a recent asdf, just unpack the
source (and/or git clone it) into ~/common-lisp/asdf/ — and if you're
using clisp or are stuck with and old unupdatable allegro-express,
then use asdf/tools/install-asdf.lisp to override your
implementation's old asdf with a newer one.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Question authority... but raise your hand first.