Next steps

[Robert Goldman]

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

> 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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20211117/08e1685b/attachment.html>