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

[Faré]

On Thu, Nov 21, 2013 at 12:45 PM, 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.
>
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?

> 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.
>
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:
>
> 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).
>
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).

> 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.
>
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.

> 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.
>
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.