Dear Robert, so I pushed two easy changes among those list I discussed on the list: Move the inline-method support to parse-defsystem Fix in-user-configuration-directory to accept files, not just directories. I also had to fix find-standard-case-symbol again, so I added regression tests. Now, when I did a make bump, I got the following error message: Transforming file upgrade.lisp... done. Rebuilding ASDF with bumped version git commit -a -m "Bump version to $(eval a=$(cat version.lisp-expr) ; echo $a)" fatal: ..: '..' is outside repository [master 9120cf7] Bump version to 3.1.4.7 4 files changed, 4 insertions(+), 4 deletions(-) I checked that it's the command `git commit -a -m '3.1.4.7'` that was complaining indeed. Why, I don't know. I tried to `git submodule deinit .` and/or `git clean -xfd`, to no avail; I see symlinks to ../ but only in subdirectories. I see no .. in my .git/* or .git* files. I hope it's not a symptom of something too bad. Do you have the same symptom? Finally, is there already a deprecation library for CL somewhere? Otherwise, I ought to write one for UIOP, and start using it for the backward-foo functions. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The government consists of a gang of men exactly like you and me. They have, taking one with another, no special talent for the business of government; they have only a talent for getting and holding office. Their principal device to that end is to search out groups who pant and pine for something they can't get and to promise to give it to them. Nine times out of ten that promise is worth nothing. The tenth time is made good by looting A to satisfy B. In other words, government is a broker in pillage, and every election is sort of an advance auction sale of stolen goods. — H. L. Mencken

Faré wrote:

In the launchpad bug at https://bugs.launchpad.net/asdf/+bug/1437480 you also mention:

...

...

I believe that we should release this as 3.2 because of the incompatibility in the API with the new functions from UIOP.

While I think we should indeed soon release 3.2, I believe that it is not so urgent that it can't wait for a few more useful changes, especially since we do provide backward compatibility functions for the old API. So I propose we release a 3.1.5 for now, and do a few more changes before we actually cut a 3.2.

I wasn't clear: I don't mean that we need to do a 3.2 release at this very moment, just that these changes are not fully compatible, so are worthy of a "greater than patch level" release. I'm not so sure about the 3.1.5, since that means stuff that's not API compatible comes out as a patch level release.

He are the few changes I believe could usefully be done *before* rather than *after* we cut a #+asdf3.2 feature:

* Most importantly, this test-system feature I've recently discussed. This change is useless until a new #+ feature is introduced, because people will have to add #+asdf3.2 and/or #-asdf3.2 in their defsystem files to depend on it, until 3.2 becomes ubiquitous (or 3.3, if the feature only makes it to 3.3).

Agreed. I think this is a very important addition, and I'd like to see it go into the release. Note that the feature would give us a way to do what you want (release 3.1.5), because we could add :asdf3.2 in at that point. On the other hand, maybe we need to have 3.2.0.1 be the next thing we push, and call it a release candidate. It may be that the release will have to be 3.2.1, but I could live with that. What do firm believers in semantic versioning do about this? Just always have their release be x.y.z when they want x.y, so that they can have a release candidate? Or do they do something like x.y.rcz? That would require a change to VERSION-SATISFIES...

* minimakefile. Can we get this in before we cut 3.2? Actually, merging before 3.1.5 would allow to test the release functions before we release an actual 3.2.

The last time I was working with minimakefile it was still at the state where every time I tried a new command, I would get a new error. I got tired of this and gave up. I'll try again, but this one is your cause: I don't care if CL never becomes a scripting language. I'm willing to run with it if it works, but if it gives me grief, I'll give up again.

* maybe some infrastructure to declare old functions obsolete and issue style-warnings, warnings, cerror or even errors when they are used. They are a few ASDF2 compatibility functions that should go, and even a few old ASDF3 misfeatures that could get a headstart in the deprecation area.

Yes, we discussed this. I have created a ticket for this: https://bugs.launchpad.net/asdf/+bug/1451431 I have added a note to that wrt your suggestion that the deprecation library live in UIOP, and be used in ASDF.

I think the syntax-control branch can wait until 3.2 is released. Hopefully, it can make it into 3.3 by next year (wow, ASDF moves slowly again)!

I think that's a Good Thing: it is a reflection of ASDF mostly just working happily, and a reflection of ASDF's critical place in the CL community's infrastructure.

Faré wrote:

...

...

While I think we should indeed soon release 3.2, I believe that it is not so urgent that it can't wait for a few more useful changes, especially since we do provide backward compatibility functions for the old API. So I propose we release a 3.1.5 for now, and do a few more changes before we actually cut a 3.2. I wasn't clear: I don't mean that we need to do a 3.2 release at this very moment, just that these changes are not fully compatible, so are worthy of a "greater than patch level" release.

Well, we do provide a backward compatible API; but it's true that the behavior on Windows has slightly changed.

We provide a backward compatible API, but we don't have a *forward* compatible one, because of the new XDG functions.

On the other hand, we have accumulated enough bug fixes and features since last October, including support for a new implementation (clasp) to warrant a release soon. Release numbers are not a scarce resource, so if you believe this requires a 3.2 release now, that just means that the further changes I'd like will have to be for a 3.3 release.

...

On the other hand, maybe we need to have 3.2.0.1 be the next thing we push, and call it a release candidate. It may be that the release will have to be 3.2.1, but I could live with that.

That's how we did the 3.1 release: pre-releases as 3.1.0.x, and release as 3.1.1. It seems to have worked out well — well except for immediately followeing it with a 3.1.2 for a bug fix :-(.

...

What do firm believers in semantic versioning do about this? Just always have their release be x.y.z when they want x.y, so that they can have a release candidate? Or do they do something like x.y.rcz? That would require a change to VERSION-SATISFIES...

We could specially parse rc as "-1", "beta" as "-2", "alpha" as -3, etc, but that sounds like dubious over-engineering to me.

Agreed. OK, the next time I push, I will push 3.2.0.1, because I'd like to have people be able to start checking for version 3.2 for the new XDG functions (and eventually the new test-operation functions). Should we push just asdf-3.2 or also uiop-3.2 (since the new XDG functions are properly UIOP)? thanks, r

Faré wrote:

...

Should we push just asdf-3.2 or also uiop-3.2 (since the new XDG functions are properly UIOP)?

(I assume you mean *features*) Actually, I don't think there's anything new asdf that warrants a feature, so I'd add a uiop feature only (and uiop has evolved enough since 2.27 that a feature could help, especially considering that at least quicklisp distributes uiop without asdf). I believe uiop/driver.lisp is the correct place for the pushnew.

OK. Should we at some point define a stable UIOP feature set, and just bump to 3.0 as a new stable point? cheers, r