[asdf-devel] In defense of ASDF & Semantic versioning

[Pascal Costanza]

On 21 Nov 2013, at 18:45, Robert P. Goldman <rpgoldman at 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:
> 
> 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.

+1

For those who want a strict handling of both cases, they can always set *break-on-signals* accordingly. (The other way around, switching from a strict error to to something to ignore, is less convenient.)

Pascal

P.S.: Please don’t over-engineer this. People will not spend a lot of time thinking about what exactly happens when what part of their version numbers change how. We need to make the barriers for contributing libraries to the Lisp community lower, not higher.

--
Pascal Costanza
The views expressed in this email are my own, and not those of my employer.