Comment 4 for bug 1366379

Robert, Fare

I've considered the aspects you describe before bothering
your with this proposal.

1. As for strengthening CCL version precision:

   Yes, fasl file format is reflected as -f86 in
   asdf:implementation-identifier for CCL. And the fasl
   format is not necessary changed between CCL releases,
   so the fasl format remains parsable/loadable by both
   ccl-1.9-f96 and ccl-1.10-f96.

   But the code stored in that file format may still be broken
   due to compiler bugs, so we may want to recompile on
   new compiler.

   Especially, if the old compiler was NOT a release, but an intermediate
   development version or a release candidate - I would want to recompile
   when I switch from 1.10 release candidate to proper 1.10.

   ASDF already segregates fasls of the same -f86 format, built
   by different releases. Example cache directories:

   ~/.cache/common-lisp/ccl-1.10-f96-linux-x86/
   ~/.cache/common-lisp/ccl-1.9-f96-linux-x86/
   ~/.cache/common-lisp/abcl-1.3.0-fasl42-linux-x86/
   ~/.cache/common-lisp/abcl-1.3.0-svn-14683-fasl42-linux-x86/
   ~/.cache/common-lisp/ecl-13.5.1-unknown-linux-i686/ ;; release 13.5.1
   ~/.cache/common-lisp/ecl-13.5.1-237af2e8-linux-i686/ ;; git version after release 13.5.1
   ~/.cache/common-lisp/sbcl-1.2.0-linux-x86/
   ~/.cache/common-lisp/sbcl-1.2.0.69-615be91-linux-x86/

   Unlike the other lisps in the above example,
   CCL's asdf:implementation-identifier never has source control revision,
   even in trunk versions. Moreover, for the other lisps the release
   version means exact source code version, while
   in CCL version 1.10 allows wide variety of
   versions, including release candidates.

   I admit that Allegro also updates itself
   by patches, and this information is omitted
   in implementation-identifier:

   ~/.cache/common-lisp/acl-8.2-linux-x86/
   ~/.cache/common-lisp/acl-9.0-linux-x86/

   But at least Allegro release candidate will not be
   named same was as a proper release (I hope).

   Therefore, I think it make sense to strengthen
   CCL implementation identifier, and svn revision
   is the only precise enough attribute for all cases.

   But I don't insist, it's just a proposal for your consideration.

2. Is -rc1 redundant if we use svn revision number.

   Only matters if you consider (1) convincing, and agree
   to strengthen CCL's implementation identifier.

2.1 Consider -rc1 as a part of human readable version number:
    1.9, 1.10-rc1, 1.10.

    If SVN revision number makes -rc1 redundant, then
    the 1.9 and 1.10 numbers are technically redundant too.

    But the human readable version number is convenient - it is
    good to understand immediately what of my lisps created that fasl directory.

2.2 The long path problem on Windows indeed exists, I"ve been bitten
     by it. But the fasl path is long because it consists of the path to the
     cache directory + the full path of the original source:

    /home/anton/.cache/common-lisp/ccl-1.9-f96-linux-x64/home/anton/prj/cl-test-grid/cl-test-grid2/agent/agent.lx64fsl

    -rc is just 3 letters, not a significant addition.

2.3 The -rc only appears in release candidate, normal
     releases don't have it, so the question is irrelevant to normal releases.