As I understand, this thread only discusses syntax and ordering rules for version numbers.
But if users see the :semver in ASDF examples and documentation, they will likely assume full semver practice is recommended by ASDF. As semver does not work for Common Lisp,
Could you elaborate a bit on "As semver does not work for Common Lisp"? I mean no programming language comes with "semver built in". It's the programmers that have to commit to "sticking to the semver rules" for it to work.
I am afraid such encouragement of its use will have lasting destructive effect on the ecosystem. So, if this new logic of version numbers is to be implemented, I would suggest to name it somehow differently.
Also, if the motivation is the desire to distinguish alpha versions from stable releases and have alpha ordered before the stable, the following approach makes it possible in the current versioning:
alpha version: 3.4.0-alpha
beta version: 3.4.1-beta
stable version: 3.4.2
In other words, never publish versions that have equal numeric parts. IMHO there is no significant practical sense in keeping even the least significant (patch) number equal between alpha and release.
semver is very much about API guarantees that are communicated by the version number. It's not "just" about the number. semver authors observed the desire from software authors to release new release lines as .0 or .0.0 and thereby a strong desire to be able to order version numbers *before* x.y.0 and x.0.0. The fact that there are other options available apparently was not a strong argument for those software authors. (btw, Perl has software version recognition built in dating from pre-semver and people work with that. However, many regret quite much that Perl - due to its built-in legacy - is unable to follow common practice. I think it makes sense for Common Lisp to recognize that semver is the predominant practice these days (while still recognizing others may not want to use version modifiers) and choose a setup which does not prevent its ecosystem to use semver at any future point.
Best regards,
- Anton
Best regards,
- Anton