component-version (version slot) unbound on ASDF after upgrade

[Robert P. Goldman]

I think that the value asdf:*asdf-version* should be assigned to the VERSION slot of the system object named ASDF on load of ASDF 2.

I'm pretty sure that (asdf:component-version (asdf:find-system :asdf)) should equal (asdf:asdf-version)

[Robert P. Goldman (rpgoldman)]

Fare writes
>
> Should we rename our current 2.140+ branch to 2.010.1 ?
> Or at some point start using 2.200 and 2.200.1 instead of 2.200 and 2.300 ?
> Or converge towards the second Feigenbaum constant?
>

Response...

I think we need to jump to something that will make ASDF's version-satisfies happier.

I think 2.010.1 is version-less-than 2.140...

We should probably move to 2.200.

Honestly, I think jumping to 3 and then going up by 3.1.0, 3.1.1 .... jump to 3.2.0, ... and so forth, would be better from the version-satisfies standpoint.

Unfortunately, since we marked things as ASDF3 in the launchpad, that's probably not a good thing to do.

I'd like us to get to a

Major version . minor version . patchlevel

discipline at some time, though.

[Faré (fahree)]

I made a vain attempt to fix this bug in 2.143. Excerpt from log:

    Actually, there's no way to automatically make sure that the ASDF version
    number is consistent between the asdf.asd and the asdf.lisp, lest we
    have scripts that enforce it at checkin or checkout time.

I'm tempted to mark the bug as "WON'T FIX".

As for bug numbering -- yeah, I suppose 2.200.1 is the conservative thing to do. We still have plenty of bugs targetted for "ASDF 2.1", though, so it'd be a mess anyway. Or can we just rename such a milestone?

[Robert P. Goldman (rpgoldman)]

On 10/25/10 Oct 25 -4:59 AM, Faré wrote:
> I made a vain attempt to fix this bug in 2.143. Excerpt from log:
>
> Actually, there's no way to automatically make sure that the ASDF version
> number is consistent between the asdf.asd and the asdf.lisp, lest we
> have scripts that enforce it at checkin or checkout time.
>
> I'm tempted to mark the bug as "WON'T FIX".

Sorry if I'm being dense --- why shouldn't we do this by means of
checkin and checkout scripts?

Or couldn't we have something like an :after method on some piece of the
OPERATE process on ASDF that will force the value of *asdf-version* into
the version slot? We could even make the ASDF system an element of a
degenerate subtype of SYSTEM

e.g.,

(defclass asdf-system (system)
  ()
)

and add an :after method on

(PERFORM LOAD-OP ASDF-SYSTEM)

or even add a default-initarg

couldn't we?

I'm probably missing a complication here....

[Faré (fahree)]

There are many ways of fixing the version slot after the system is loaded. Unhappily, none of these ways will tell you the version BEFORE the system is loaded, thus foiling any hope of correctly using :version to control compatibility at planning time.

A checkin/checkout script is your only hope, and I'm not the one who will write it.

[Robert P. Goldman (rpgoldman)]

On 10/25/10 Oct 25 -8:15 AM, Faré wrote:
> There are many ways of fixing the version slot after the system is
> loaded. Unhappily, none of these ways will tell you the version BEFORE
> the system is loaded, thus foiling any hope of correctly using :version
> to control compatibility at planning time.
>
> A checkin/checkout script is your only hope, and I'm not the one who
> will write it.
>

I will try to get a few minutes with the git book today and see if I can
figure out how to do this.

If I can, I will push a branch with the git script for experimentation.

[Robert P. Goldman (rpgoldman)]

I think this page may provide clues for how to do what we want: http://progit.org/book/ch7-2.html

I will see if I can figure out how to make this happen.

[Robert P. Goldman (rpgoldman)]

OK, smudge/clean is NOT the wrong thing, because it's configured per-developer not on the main system. So the last idea was a blind alley. Looking into alternatives.

[Robert P. Goldman (rpgoldman)]

Faré: I just looked at your last commit, where you modified your script for tagging to push the version number in to asdf.lisp. Is there some reason we couldn't push the version number into asdf.asd at the same time and in the same way?

[Faré (fahree)]

The script is a remnant of gwking times. I am not actually using it, since I want to change to bump the version every time asdf.lisp changes, with a meaningful commit message, which this script doesn't support. Instead, I painfully increment the version number every time.

What about incompatibly changing the ASDF version number to 2.0.10 ?

[Faré (fahree)]

As far as scripts go, we could probably get inspiration from what Alastair Bridgewater wrote for his SBCL git repository...

[Robert P. Goldman (rpgoldman)]

I am very reluctant to do anything involving retrograde motion of the version number....

What about jumping to something like 2.500.0 and then incrementing the least significant digits from there?

[Robert P. Goldman (rpgoldman)]

WRT the scripts, what about whacking all those that are dead code? Actually, we should probably start a separate ticket that has to do with auditing the scriptage. I messed up the repo a bit when I last tried to do a release, ending up with a desynchronized and puzzling "release" branch...

WRT the numbering, git makes it hard to do the kind of textual substitution we want in an automatic way without individual configuration by all developers. That's probably reasonable --- it's a revision control system, not a preprocessor. I chased that blind alley for a while. Now I think it might be better to have a "version-cookie" file and have asdf.lisp and asdf.asd read its contents as a side-effect of loading. Somewhat icky, but it would ensure that the version numbers are consistent, and would work for everyone who has a checkout.

[Faré (fahree)]

OK, so let's move to 2.200, 2.201, 2.202... for the "release" branch, which can now be a mere release tag, and 2.200.1, 2.200.2, ... for the "master" branch when it diverges from release.

As for scripts, the main thing, that ought to be on the server, it something that *checks* that
1- if the code changed, then so did the version number (i.e. asdf.lisp, asdf-ecl.lisp or asdf.asd).
2- the version number is the same everywhere (asdf.lisp, asdf.asd, maybe also asdf-ecl.lisp).

Then, developers may or may not have scripts on their side, the thing that matters is enforced.

Once again, ask nyef about his SBCL git scripts.

[Faré (fahree)]

Hopefully fixed in 2.011.5.

NB: So far we adopted the a.b.c version convention, but without jumping forward to 2.150 or 2.200, and without removing the 0 in 2.011. A few old ASDF versions have a superior version number, e.g. ASDF 2.147, but hopefully, they are not being used in the wild, so the "new" numbering convention is compatible with the old one, as far as versions seen in the wild are concerned.

[Faré (fahree)]

Released in 2.012