Upgrade failures for asdf-3.1.7 and later

[Daniel Kochmański]

Is there any chance for specification of the "core ASDF protocol" -
subset guaranteed to not change every few years, so one may write today
systems which will be loadadable in the future?

Regards,
Daniel

Faré writes:

> This is totally intentional and well-documented.
>
> Do NOT use the central-registry if you don't know what you're doing. Use
> the source-registry as recommended. (Or, if you truly insist, reinitialize
> the central-registry after upgrade; upgrading from ASDF 2 will create a
> fresh ASDF package; see asdf/tools/load-asdf.lisp for how to load ASDF
> while supporting backward compatibility back to ASDF 1 the hard way).
>
> Do NOT use ASDF 2.26 (from October 2012), ever. Help me convince Xach to
> stop distributing that bitrotting piece of maintenance nightmare.
> Seriously, it's a shame that Quicklisp isn't distributing ASDF 3.1.7 (from
> May 2016), which is the very stable culmination of the 3.1 series and works
> great with all its systems. And I totally understand that Quicklisp must be
> conservative and should not upgrade to the latest 3.2.1 (from April 2017)
> yet. Considering how badly ASDF 2.26 now behaves when trying to load
> systems from Quicklisp, I wonder if Xach even ever tests it; I bet not.
> Alternatively, to show how utterly ridiculous his attitude is, convince him
> to distribute ASDF 1.85 (from May 2004) instead, the perfect gem that Dan
> Barlow bequeathed us (). Or no more recent 1.366 (from September 2009), the
> last version wholly untainted by my code contributions.
>
> -#f
>
>
> On May 3, 2017 2:23 PM, "James M. Lawrence" <llmjjmll at gmail.com> wrote:
>
> Starting with a bare lisp image (e.g --no-userinit --no-sysinit for
> SBCL), the following signals a "component not found" error:
>
> (load "asdf-2.26.lisp")
> ;;; or whatever system you want
> (push #p"~/quicklisp/dists/quicklisp/software/alexandria-20170227-git/"
>       asdf:*central-registry*)
> (load "asdf-3.2.1.lisp")
> (asdf:load-system "alexandria")
>
> The first bad commit is https://github.com/fare/asdf/commit/3a9457a
>
> I hope this wasn't intentional? Ideally an old asdf version would
> never get loaded, but practically speaking it sometimes does (e.g. on
> LispWorks PE and CLISP). And if that happens, thereafter one is unable
> to load a system that requires asdf-3. The above case is a
> whittled-down version of a quickloading problem.
>
> Best,
> lmj


--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański      | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi