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.