>> 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 _______________________________________________ asdf-devel mailing list [email protected] http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
