Versioning

[Robert Goldman]

On 17 Nov 2021, at 15:12, Eric Timmons wrote:

> On 11/17/21 2:38 PM, Robert Goldman wrote:
>> On 17 Nov 2021, at 13:31, Robert Dodier wrote:
>>
>>     On Wed, Nov 17, 2021 at 10:45 AM Robert Goldman 
>> rpgoldman at sift.info
>>     <mailto:rpgoldman at sift.info> wrote:
>>
>>         I favor something like this because it would be nice to have
>>         prerelease versions of ASDF that perform version checks 
>> properly.
>>
>>         What I mean is, if we are going to add a feature in version 
>> 3.4,
>>         right now that would be in a prerelease version with a 
>> version
>>         number of something like 3.3.5.22
>>
>>         It would be a lot better for realistic testing if we could
>>         instead use 3.4.0-alpha1 or 3.4.0-1 and have ASDF know that
>>         3.4.0-1 comes before 3.4.0, not after.
>>
>>     Hi Robert, hi everyone. I haven't been following closely, but 
>> while
>>     you are working out details, let me just mention that I recommend
>>     against version numbers that require special interpretation to
>>     discover their ordering, e.g. 3.4.0-1 < 3.4.0.
>>
>>     Mostly I'm just thinking that somebody's not going to get the 
>> memo
>>     (it's usually me).
>>
>>     For what it's worth, and all the best.
>>
>> I guess that would be an argument for using something more obvious 
>> than |-|, like the string |alpha| so |3.4.0-alpha1| or |3.4.0alpha1| 
>> instead of |3.4.0-1| since there the meaning should be relatively 
>> obvious.
>>
>> My feeling is that if a user misinterprets |3.4.0-1|, then shame on 
>> me. But if a user misinterprets |3.4.0alpha1| then shame on them.
>>
>> I'm not sure how that would align with semver...
>
> Erik already sent out some examples of ordering with semver. But it is 
> worth noting that 3.4.0-1 *is* valid semver and the ordering would be 
> 3.4.0-1 < 3.4.0-alpha
>
> So to prevent misinterpretation of 3.4.0-1, ASDF could either promise 
> to always use something like alpha/beta/etc, use something else like 
> PEP440 (I believe that grammar always requires an alphabetic character 
> for pre-releases), or bake its own grammar.
>
> One thing that's nice about the semver grammar is its flexibility. I 
> have some scripts that can generate a version string from a git repo 
> that lets you easily order versions based on things like when they 
> branched off the default branch. But if we want ASDF to disallow 
> things like 3.4.0-1, I'm happy to build my own system that uses the 
> new API to allow the use of semver strings.
>
> Another option is to choose something compatible with Debian's version 
> strings. I'm having a little trouble grokking it at the moment, but it 
> seems to be even more freeform than semver and adds an optional epoch 
> prefix.

What might be nice would be to support a *subset* of semver by default 
-- not allowing the numerical prerelease flagged with `-` -- but do so 
in a way that is extensible.

Here's my rationale: I would like to provide a relatively simple 
semantic versioning that is also compatible with automatically detecting 
and rejecting ill-formed version strings.

So, for example, we could (by default!) split the version strings by 
`#\.` and `#\-` and *reject* any string bounded by `#\.` that is not 
numerical.

We could demand, again by default, that the substring following the 
`#\-` be of some constrained form: e.g., Greek letter name followed by 
optional numeral.  For that matter, we could just say "hey, alpha and 
beta are enough" and reject anything but those two.  That would be a 
nice alternative to having a big table of Greek letter names in ASDF!

Finally, for those who want to really go for it, we could add a 
`:version-scheme` keyword to `defsystem`, which would initially default 
to `:unconstrained`, but then through the standard process of warning 
and then erroring, migrate to `:standard` (or perhaps `:asdf`) as the 
default, but let anyone who wants to make up their own versioning 
scheme.  `semver` would be an obvious extension.

Hm.  That's a bit more complex than I had hoped, but it would mean ASDF 
systems would initially continue to work, it provides for some error 
checking, and a path to extension.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20211117/c0566f8d/attachment-0001.html>