Versioning

[Eric Timmons]

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