New version of ASDF pushed

[Robert P. Goldman]

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.