Semantic versioning makes one good thing - it concentrates on difference between API compatible changes and API incompatible changes.
This is an important concept and it remains valid for binary components and for source code.
But semantic versioning is not a complete solution. It allows to detect incompatibility problem, but it doesn't say how to solve or avoid this problem.
I wouldn't want to see library authors advised: "You can break API compatibility; in this case just increase major number in the :version attribute of your asfd:defystem, and the problem is solved."
It does not solve the problem. For example, I would not want to see a library like alexandria to break compatibility by renaming half of it's functions and reflecting this just by :version attribute. Suppose postmodern adopted new alexandria, but hunchentoot hasn't. As new and old alexandria can not be used simultaneously, my application build with hunchentoot and postmodern can not benefit from improvements and fixes in the new postmodern until hunchentoot is updated.
Releasing an incompatible library version essentially splits lisp world into two sets: libraries depending on new version and libraries depending on old version. And these two sets become incompatible and can not be used in the same application.
Doing so would impose a significant friction to the lisp wold evolution. Once you depend on a library from one set, you are locked in this set.
If we put the incompatible version into new package (alexandria2 or carthage, whatever) and allow it to coexist with the old version, we allow other libraries to evolve freely, without constraining the development agility.
I hope it is clear by now, that the library maintainer is not expected to provide support for old versions. Just leaving the old versions available for use results in sigificant benefits.
We can generalize it to other forms of :version specifiers and :depends-on specifiers, be it list designators, open ranges, etc. In general this may be described as consumer speficies some contraints on the supplier library consumer can work with, and the supplier describes itself so that the library loader, when loads an application dependencies, can solve a kind of constraint satisfaction problem and chose from the library verions available on the system the versions which satisfy all the consumers in the application.
People can experiment with various forms of the supplier properties/contrains specifiers: dot separated numbers, lists of features, etc. But it's not enough to just describe the constraints. We also need a guidelines or strategy for developers to ensure it is possible satisfy all the constraints. If my application dependency tree contains two incompatible versions of a library (some-lib 1.0.0 and some-lib 2.0.0 if we use semantic versioning), then it is impossible to satisfy such requirments, unless these two versions can be loaded simulaneously.
22.11.2013, 01:15, "Faré" fahree@gmail.com:
When you compile, you can detect API discrepancy, etc. In the C world, you do that with autoconf, #ifdef, etc. A same piece of source code will happily compile against a wide range of versions of the C library, and usually doesn't check version numbers, only the availability of given functions and CPP macros. Most of my C programs can compile unmodified against linux libc4, libc5, libc6 and whichever BSD libc, etc.
No, consider when libc7 is released, and some functions are removed or changed behaviour. It may break you C programs, because your code can not be prepared for arbitrary future changes. That's the question of backward compatibility - how supplier components should evolve to allow existing clients to remain functional.
I think it is not bad to make :version-satisfies customizable. In this case I would also suggest make :version not necessary a string, but allow some other values, like list of tags, etc.
Robert, if we want to continue from the version mismatch condition, the condition object might list the alternatives available: other versions of the required ASDF systems which are found. And if no alternatives available, we can't continue.
Best regards, - Anton