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

[Robert P. Goldman]

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