Hi,

in addition to Pascal's great summary, you can also have a look at the Semantic Versioning web site:

https://semver.org/

Cheers

Kambiz

----- On 27 Nov, 2020, at 15:47, Pascal Bourguignon pjb@informatimago.com wrote:

Hi!

Le 27/11/2020 à 13:51, Marco Antoniotti a écrit :

...

Hi

Sorry for the general noise, not necessarily related to the issue at hand.

I know I am a P.I.T.A.,  but I kind of concluded that versions of the kind

YYYYMMDD

Are better than

major.minor.small.itsy.bitsy.bit

What do you think?

Well, using a timestamp as version number is not as informative for the user as the semantic major.minor.bug version number.

The usual meaning being that:

• the major is incremented when incompatible changes to the API are

made: users updating from one major to another should expect to have to invest some work to upgrade their stuff for the new version.

• the minor is incremented when compatible changes to the API are made

(additions to the API, or change, with a compatibility layer provided): users updating from one minor to another can expect to only have to recompile their stuff for the new version, if at all, and no more work.

• the bug is incremented when bug corrections are made, without any

change to the API: user updating from one bug to another can expect total compatibility and no work at all on their part.

Instead of that, if you use a timestamp as version number, you now have to keep metadata, such as what versions are LTS (long term support), or other such attributes.  This works for whole distributions, but not for single libraries.

-- __Pascal Bourguignon__

To be clear, I did not introduce semantic versioning in ASDF, Dan Barlow, the original author did. Actually, by making ASDF 2 and ASDF 3 explicitly backward-compatible with their predecessors, I violated the rule that says that a major version change equates to API incompatibility, and indeed had to change the definition of version-compatible-p accordingly (and many other systems defied this rule). A rule that makes sense for library ABI compatibility but not so much for source-level compatibility.

Also, an advantage of the current ASDF numbering scheme is that it makes it clear WHICH version from the trunk you've been forking out of. That only makes sense if there is a strong trunk and branches that don't deviate too much from it, of course, but that's always been the goal for ASDF.

Finally, no, please do NOT include your local versions in your merge requests. It doesn't help at all and it hinders a lot.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It is deplorable that many people think that the best way to improve the world is to forbid something. However, they're morally more advanced than the people who think the best way to improve the world is to kill somebody. — John McCarthy

On Fri, Nov 27, 2020 at 11:00 AM Robert Goldman rpgoldman@sift.info wrote:

I'm going to table this discussion on the grounds that "this ship has sailed." Faré set the pattern for version numbering, for good or ill. Since that is the case, I'm going to decline to get into the discussion of the "good or ill" question, and simply say that it would be far too disruptive to change the version numbering scheme at this point.

Best, R

On 27 Nov 2020, at 6:51, Marco Antoniotti wrote:

Hi

Sorry for the general noise, not necessarily related to the issue at hand.

I know I am a P.I.T.A., but I kind of concluded that versions of the kind

YYYYMMDD

Are better than

major.minor.small.itsy.bitsy.bit

What do you think?

All the best

Marco

On Fri, Nov 27, 2020 at 4:16 AM Mark Evenson evenson@panix.com wrote:

...

I’m a little unsure of whether the “Committee for Ongoing and Perpetual ASDF maintenance” (hi Robert!) wishes us to include the results of “file:bin/bump-version” in submitted patches.

I have a small ABCL-specific patch dealing with UIOP:PARSE-UNIX-NAMESTRING when loading system definitions from zip archives for which I have used bump-version to denote as version “3.3.4.0.1”. I’ve not quite finished my testing to ensure that previous versions of ABCL work well with it, but when I do, do you wish me to include the use of “bump-version” with the patch or is that something the Committee prefers to do on its own?

yours, Mark

-- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

-- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY