Problem: asdf's current versioning scheme will declare that asdf 3 is incompatible with asdf 2, so anyone who tries (asdf:version-satifies "3.0" "2.26") is in for a big disappointment.
As long as we reasonably don't break compatibility, I propose we keep the asdf 2 series going indefinitely.
That's a good point.
If we are going to stick to ASDF 2 indefinitely, would it be a problem to move to an xx.yy.zz format of versioning, where delta(yy) = change in API and delta(zz) = patch?
The problem is what constitues a "change in API"; as long as we preserve what's documented, that can be in the eye of the beholder, and we failed to document much.
That said, I agree there should probably be a #+asdf2.27 or something, since I'm introducing some several major changes: asdf-bundle, building those who depend-on a modified system, proper timestamps, yet another complete rewrite of traverse, removal of :feature and :if-component-fails, etc.
The reason I suggest this is that it might be easier to keep track of the way in which the xx's correspond to features you need that way. Most people who are worried about whether their ASDF system definitions will work could safely ignore the zz's.
I don't think that will work any the better than now. You will still have to look at the debian/changelog or git log to see when a feature was introduced or removed.
Personally, I have pretty much lost track of when features I need were added to ASDF.
If you care to specify the proper version of asdf to depend on, the release-to-release debian/changelog and the commit-to-commit git log are here to help.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org What is mind? No matter! What is matter? Never mind! — Bertrand Russell's Grand Mother, In Karl Popper, The Unended Quest