Versioning

[Stelian Ionescu]

> On 19 Nov 2021, at 15:25, Jason Miller wrote:
> 
>> On Fri, 19 Nov 2021 22:02:11 +0100 Erik Huelsmann <ehuels at gmail.com> wrote:
>> 
>>> 
>>> 
>>> On Fri, Nov 19, 2021 at 9:51 PM Anton Vodonosov <avodonosov at yandex.ru>
>>> wrote:
>>> 
>>> 
>>>> 
>>>> 
>>>> - etimmons@, rpgoldman@
>>>> 
>>>> "Erik Huelsmann" <ehuels at gmail.com>:
>>>> 
>>>> 
>>>>> Could you elaborate a bit on "As semver does not work for Common Lisp"?
>>>>> 
>>>> 
>>>> 
>>>> I've opened an issue in the SemVer github repo:
>>>> https://github.com/semver/semver/issues/771
>>>> (Don't want to repeat this explanation over and over in many discussions).
>>>> 
>>>> 
>>> 
>>> 
>>> "One bad programmer can break more than 10 good ones can fix": the issue
>>> you raise is bad engineering (increasing the version number simply because
>>> you can) and is not a problem semantic versioning is trying to solve. What
>>> it *does* try to solve is that the engineers working on the software can
>>> see the problems coming.
>>> 
>>> 
>> 
>> 
>> I disagree, in the example authentication-1.1.2 upgrades a dependency of
>> commons-logging from 1.x to 2.x *because* commons-logging changed its API.
>> Presumably authentication did *not* change it's API because it's following
>> semver and only incremented the minor version. However, upgrading from
>> authentication 1.1.1 to 1.1.2 will break if any other components depend on
>> commons-logging-1.* since in Lisp (and many other languages) it's not possible
>> to load two versions of the same system.
>> 
>> So long as two different versions of the same system cannot be used in the same
>> image, this is a real problem with semver. How large of a problem it is can
>> certainly be debated (I don't find it to be that big of an issue in practice).
>> 
>> 
> I'm not sure that I see this as a CL-specific problem. If you have a C++ program that uses one boost version and it uses a library that requires a different boost version, you have the same problem.
> 
> I also don't think that this is a problem with semantic versioning: the boost people use what we might call "anti-semantic versioning," but they still wreak havoc with the world. The problem isn't that semantic versioning breaks everything, the problem is that different libraries evolve at different rates, and that causes stuff to break.
> 
> I would argue that this shows the *strength* of semantic versioning: no, it doesn't magically solve the problem of version skew, but in at least some cases it tells you that you have version skew, and tells you where to look for a solution, instead of leaving you flailing around trying to figure out why your code has suddenly stopped working.

My personal experience is that semver is of no help because 1) authors don't really know when or how to increase the number, most have adopted semver because it's fashionable and 2) the users don't really know what the true minimum version is and just winge it by selecting whatever recent version they're working with as minimum requirement.

In the end both the release version and the dep versions are nothing more than suggeestions and the only sure way to know if integrating N libraries works is to try to load them all together and run their own test suites plus your application's test suite.


--
Stelian Ionescu