I would suggest if you do this, we might want to offer some syntactic means to get the old behavior. Certainly there are cases where a library supplier may change the API in ways that mean "any version from 2 on" will be the wrong thing and what is wanted really is "version 2, not version 1, and not version 3." There have definitely been cases where upgrading a library will break dependent systems: I don't think we should have a build system that can't deal with that case. Best, R "Faré" <fahree@gmail.com> wrote:
Looking at packages in quicklisp, it appears that no one explicitly calls version-satisfies and really relies on the fact that it isn't the same as version<= (actually, several packages, all written by me, go through some pains to emulate version<= in spite of only version-satisfies being available in asdf 2).
On the other hand, 41 different .asd files rely on (:version ...) constrained dependencies, and may or may not expect a different major version to be considered as incompatible.
So, is anyone going to complain if I do as Xach suggests and have version-satisfies be an alias for version<= ?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If this country is worth saving, it's worth saving at a profit. — H. L. Hunt This country can only be saved if it can be saved at a profit. — Patri Friedman
On Thu, May 16, 2013 at 2:03 PM, Faré <fahree@gmail.com> wrote:
What about making version-satisfies return t?
I could do (and implemented that as version<=), but that would violate the previous contract. Not that I am aware of anyone relying on the previous contract.
What do people here think is the right thing?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org One of the greatest discoveries a man makes, one of his great surprises, is to find he can do what he was afraid he couldn't do. — Henry Ford
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.