On Thu, Nov 21, 2013 at 12:45 PM, Robert P. Goldman rpgoldman@sift.info wrote:
Faré wrote:
I'm going to take that as a vote to implement a continuation restart for version mismatch errors. [Yes, I'm grasping at straws! ;-)]
I vote NO to that.
Usually I find myself in agreement with you, but in this case I find myself two for two against, so I will share my rationale, and then propose a compromise solution:
- If one wants a programming language + environment that won't permit
you to expressly shoot yourself in the foot, then there's always Haskell, Pascal, and Ada, among others. I don't think it's our job to do that. I'm ok with providing protective warnings to keep the programmer from harming him or herself, but I don't think it's our job to prevent him/her from doing what s/he wants, assuming that it's clear that s/he understands the situation. Hence my suggestion that we allow people to continue through a version error.
Well, make it a CERROR if you want, in case a user wants to find out exactly what breaks, and maybe identify the client system as having an overly strict version requirement. But really, if a system has a version constraint, (a) it ought to be there for a reason [I don't see developers gratuitously add version constraints where not needed] and (b) why not upgrade the provider system?
- In my experience, the errors one gets when upgrading a dependency
that has changed its API are so odd, unpredictable, and difficult to trace to root cause that we should provide what help we can.
I think that telling the user about a version mismatch, and hence suggesting that he should upgrade the provider system, is already the greatest help we can provide.
That said, there is clearly an *enormous* range of different opinions on this issue, and these are all reasoned opinions. So I suggest a compromise:
- For those who like semantic versioning, revert to the behavior that
an expressly indicated API upgrade by the supplier causes a signal to be conditioned. So if I release floyd-warshall 2.0, systems requiring 1.x will see a condition.
For those who *don't* like semantic versioning, this condition will be a WARNING, and not an ERROR. Those who *really* like semantic versioning can establish a handler for this warning that will treat it as an error (possibly continuable).
I contend that the provider system, not the consumer system, should specify whether it's using semantic versioning or not.
With my proposed :backward-compatible-to keyword, you would specify: (defsystem floyd-warshall :version "2.1.4" :backward-compatible-to "2.0" ...)
Alternatively, it could specify a function to compare versions: (defsystem floyd-warshall :version "2.1.4" :version-satisfies 'uiop:version-compatible-p)
The latter alternative has the advantage that people can specify version schemes different from dot-separated integers, if they want (in which case parse-defsystem should have some checks relaxed).
- #1 will meet the needs of those who want to be able to shoot
themselves in the foot. Now ASDF will have two conditions for version mismatch: one for library too old, and one for library (possibly) too new. Since the first condition is almost always really bad, we don't provide a continuation for it, and Faré should be satisfied. Since the second condition is a WARNING, I'm satisfied that if a library developer wishes to signal a disruption in his/her API, I will be so informed.
I don't think there should be a warning, but only a (c)error. I don't think the consumer should specify semantic versioning, but the provider, at which point a cerror is appropriate.
Now what if provider at version 20 says it provides compatibility back to version 10, and consumer is ready for version 15 but includes workarounds to support the system back to version 5? Maybe consumer should be able to specify two versions: "I'm tested to work with version 15, but am supposed to work with version 5". Then we check that the two ranges have non-empty intersection.
- I'm OK with upper and lower version constraints. I don't think it's
a substitute for semantic versioning, since it doesn't allow information to flow from a library supplier to a library consumer. But I agree that it's valuable for the case where a library consumer has looked at the new version of the library, knows that the change is incompatible, and for some reason will not or has not yet adapted the client library.
I don't think the consumer client should specify semantic versioning or not. It's not information the consumer has. Only the provider has this information.
If the consumer has decided that new versions of the library are not compatible, then either library has to be fixed to restore compatibility, or the provider library needs be forked if the compatibility is not restorable and the consumer won't adopt the new API. Version blacklists can be useful, but should not include open-ended ranges: if you're not going to support future versions of the provider system, you should fork it to keep API support.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I'm pro-choice, or as I call it pro-Go-Mind-Your-Own-Goddamn-Fucking-Business. For it's always SOMEONE's choice. Here: not yours, the mother's.