Next steps

[Eric Timmons]

On 11/17/21 12:24 PM, Didier Verna wrote:
> Stelian Ionescu wrote:
> 
>>> Mostly sounds good to me. Assuming you're still interested in more
>>> expressive version numbers and constraints for 3.4, I'll work on moving
>>> that off the back burner.
>>
>> Adding fine-grained version constraints would be a big mistake.
> 
>    I do not have the time to check this thoroughly right now, but I
>    recall having suggested that ASDF shouldn't impose any constraints on
>    version "numbers", but rather defer version comparison to libraries
>    when they use a version numbering scheme that ASDF doesn't understand.
>    This can be done by providing generic functions like version-> etc.,
>    and letting people provide methods on them. >
>    There may even be an issue and a patch lurking around somewhere.
>    Again, sorry for being fuzzy, this is just from the top of my head.
> 

Hi Didier,

I started from your patch on this, with the intention of allowing 
arbitrary version strings (so long as the protocol is fully implemented).

I'd like to also extend ASDF's default to be more than just 
dot-separated numbers. The leading contenders at the moment are "semver 
style" where prerelease info is separated by a #\-, "build" metadata 
separated by a #\+, and no post-release info (NOTE: I am just talking 
about version string grammar here, *not* about compatibility 
constraints!) and something like PEP 440 
<https://www.python.org/dev/peps/pep-0440/>, which as I recall is very 
similar to the style you prefer.

I have a preference toward the semver style because it's less 
restrictive and there's no notion of "canonical form" (unlike PEP 440), 
so it's easier to implement.

-Eric