Versioning

[Robert Goldman]

That sounds like a great solution.

On 17 Nov 2021, at 16:33, Eric Timmons wrote:

> On 11/17/21 4:55 PM, Robert Goldman wrote:
>> 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 <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.
>>
>
> I see what you're getting at. I already have the full semver parsing 
> and ordering functionality implemented as part of !169. So I'd lean 
> toward shipping :semver and :standard/:asdf out of the box.
>
> :standard/:asdf would signal an error if the version string is not of 
> the form X[-Y[.Z]]. Where X is a series of dot separated integers 
> (what we have currently), Y is in [alpha, beta, rc], and Z is a single 
> integer.
>
> That would make :standard versioning a strict subset of :semver, with 
> the same ordering relations. It also establishes clearly that we think 
> alpha, beta, and rc are all that you need a vast majority of the time.
>
> -Eric