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: 1. 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. 2. 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. 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: 1. 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). 2. #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. 3. 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. Does this provide some minimal level of satisfaction to all? I think it's a reasonable compromise, allowing those who want semantic versioning in a stronger sense to have it, without unduly burdening those who don't. Best, R
