Anton Vodonosov wrote:
The manual says: "the :version, :author, description and other [defsystem] fields are not required but they provide documentation and information for people that want to use this system. It also says in the section about asdf:operate: "If a version argument is supplied, then operate also ensures that the system found satisfies it using the version-satisfies method."
From some other places in the manual we can even guess how version-satisfies work.
Still, I think it was too much to expect from closer-mop to encode API compatibility information in the version identifier. Note also, in 2009 ASDF didn't consider version "0.6" as satisfying requirement for "0.55":
Yes, that's because the version scheme in ASDF is not a sequence of period-separated integers, but a sequence of period-separated strings. That was in ASDF 1, and we didn't dare mess with it. Pascal was very kind about this oddity, and has tweaked his revision numbering to fit ASDF's constraints.
http://lists.common-lisp.net/pipermail/moptilities-devel/2009-December/date....
When Faré wrote up the design rationale for ASDF, one of the principles was that ASDF should ask the right person for the right information.
For example, the library should not dictate where files go -- that's the job of the library's installer (user). The library itself knows where its components are *relative to the installation* -- that's information the library implementor will have, which the installer will not have.
Similarly, if I am the library supplier, I am the one who knows when I have changed the API incompatibly. That is why major component version changes were intended *not* to satisfy version requirements that have different major components. This is reasonable, because it provides a channel of information from the library supplier, that can be checked automatically, and if the downstream is still compatible, it should be a relatively easy fix (but is it? I don't know if there's a good way to say "I'll accept version 0.55+ or 1.0+").
The only other option would be to have the library client provide both upper and lower bounds on the version numbers that the client will accept. But, except for cases of *known* upgrade incompatibility, this is information that the library client simply cannot have.
The rules here are simple and easy to understand: if you change the API in an incompatible way, bump the major version number.
Yes, this rules out the false modestly of version numbers like 0.0.145, which looks like an alpha, but in fact turns out to be the fifth full release, but that's a sacrifice we can all live with! ;-)
As my own devil's advocate, the counter-argument is that the state of the art in CL libraries is so poor that even getting a version number is unusual. But this seems to be a counsel of despair: it says that since we have a bad state of affairs now, we are doomed to live with it forever.
I suppose I could take a little while and write up a candidate "versioning systems with ASDF" node for the ASDF manual, and push it for consideration by the community.
Also, as we speak about versioning, I have been trying to use semantic versioning as described at http://semver.org/ and I don't think it is a silver bullet - it doesn't solve all problems.
Isn't the subtitle of /The Mythical Man-Month/ "No Silver Bullet"?
Yes, this doesn't solve every problem, but it might give you a useful warning if your upstream has changed under you.... Pascal's case is an odd one, because the bump to 1.0 is, in some sense, a false positive.
OTOH, it's not really so bad to have to take a look at a library that has seen no commits in three years.
Cheers, r