Re: Next steps

[Martin Simmons]

I assume "any version since October 2020" would be written something like
"version later than or equal to 20201001"

Or maybe "version later than or equal to 20201101" if that's what "since
October 2020" means :-)

__Martin

> On Thu, 18 Nov 2021 10:57:45 -0600, Robert Goldman said:
> 
> What I meant is that ASDF does not "understand" that 20201015 is a 
> three-part version, whose first part is "2020" second is "10" and third 
> is "15".
> 
> So note that my example is "any version since October 2020." And yours 
> is "any version since October *fifteenth* 2020.
> 
> 
> On 18 Nov 2021, at 10:53, Marco Antoniotti wrote:
> 
> > Why would ASDF not understand "version later than 20201015"?  I am
> > perfectly fine with using the full 8 digit timestamp.
> >
> > MA
> >
> > On Thu, Nov 18, 2021 at 4:24 PM Robert Goldman  
> > wrote:
> >
> >> On 18 Nov 2021, at 7:35, Eric Timmons wrote:
> >>
> >>> On 11/18/21 3:45 AM, Marco Antoniotti wrote:
>  Sorry but I am missing something.
> 
>  It was said in this thread (don't remember who, apologies) that
> 
>  MMDD
> 
>  would work.  Will it?
> >>>
> >>> Yes. MMDD is currently a valid version string (assuming it's all
> >>> digits). Whatever we choose will allow a superset of what's already
> >>> allowed.
> >>>
> >>> -Eric
> >>
> >> That's true, but possibly stating the obvious: ASDF does not
> >> "understand" a version string like that.  So you can't say "any 
> >> version
> >> since October 2020 will work." Getting something like that to work 
> >> would
> >> be an exercise for the extension protocol.
> >>
> >> This actually might make a good test case for us to see if the 
> >> proposed
> >> protocol (versioning method keyword initarg for defsystem) makes 
> >> sense.
> >>
> >> R
> >>
> >
> >
> > -- 
> > Marco Antoniotti, Professortel. +39 - 02 64 48 79 01
> > DISCo, Università Milano Bicocca U14 2043
> > http://dcb.disco.unimib.it
> > Viale Sarca 336
> > I-20126 Milan (MI) ITALY
> 
> 
> 

Re: Next steps

[Marco Antoniotti]

I understand: I am not expecting ASDF to understand any three part version
in my case.

I'd wager that most cases are covered by the 8-digit timestamp scheme.

All the best

Marco


On Thu, Nov 18, 2021 at 5:57 PM Robert Goldman  wrote:

> What I meant is that ASDF does not "understand" that 20201015 is a
> three-part version, whose first part is "2020" second is "10" and third is
> "15".
>
> So note that my example is "any version since October 2020." And yours is
> "any version since October *fifteenth* 2020.
>
> On 18 Nov 2021, at 10:53, Marco Antoniotti wrote:
>
> Why would ASDF not understand "version later than 20201015"?  I am
> perfectly fine with using the full 8 digit timestamp.
>
> MA
>
> On Thu, Nov 18, 2021 at 4:24 PM Robert Goldman 
> wrote:
>
>> On 18 Nov 2021, at 7:35, Eric Timmons wrote:
>>
>> > On 11/18/21 3:45 AM, Marco Antoniotti wrote:
>> >> Sorry but I am missing something.
>> >>
>> >> It was said in this thread (don't remember who, apologies) that
>> >>
>> >> MMDD
>> >>
>> >> would work.  Will it?
>> >
>> > Yes. MMDD is currently a valid version string (assuming it's all
>> > digits). Whatever we choose will allow a superset of what's already
>> > allowed.
>> >
>> > -Eric
>>
>> That's true, but possibly stating the obvious: ASDF does not
>> "understand" a version string like that.  So you can't say "any version
>> since October 2020 will work." Getting something like that to work would
>> be an exercise for the extension protocol.
>>
>> This actually might make a good test case for us to see if the proposed
>> protocol (versioning method keyword initarg for defsystem) makes sense.
>>
>> R
>>
>
>
> --
> Marco Antoniotti, Professortel. +39 - 02 64 48 79 01
> DISCo, Università Milano Bicocca U14 2043http://dcb.disco.unimib.it
> Viale Sarca 336
> I-20126 Milan (MI) ITALY
>
>

-- 
Marco Antoniotti, Professortel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043http://dcb.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY

Re: Next steps

[Robert Goldman]

What I meant is that ASDF does not "understand" that 20201015 is a 
three-part version, whose first part is "2020" second is "10" and third 
is "15".


So note that my example is "any version since October 2020." And yours 
is "any version since October *fifteenth* 2020.



On 18 Nov 2021, at 10:53, Marco Antoniotti wrote:


Why would ASDF not understand "version later than 20201015"?  I am
perfectly fine with using the full 8 digit timestamp.

MA

On Thu, Nov 18, 2021 at 4:24 PM Robert Goldman  
wrote:



On 18 Nov 2021, at 7:35, Eric Timmons wrote:


On 11/18/21 3:45 AM, Marco Antoniotti wrote:

Sorry but I am missing something.

It was said in this thread (don't remember who, apologies) that

MMDD

would work.  Will it?


Yes. MMDD is currently a valid version string (assuming it's all
digits). Whatever we choose will allow a superset of what's already
allowed.

-Eric


That's true, but possibly stating the obvious: ASDF does not
"understand" a version string like that.  So you can't say "any 
version
since October 2020 will work." Getting something like that to work 
would

be an exercise for the extension protocol.

This actually might make a good test case for us to see if the 
proposed
protocol (versioning method keyword initarg for defsystem) makes 
sense.


R




--
Marco Antoniotti, Professortel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043
http://dcb.disco.unimib.it

Viale Sarca 336
I-20126 Milan (MI) ITALY

Re: Next steps

[Marco Antoniotti]

Why would ASDF not understand "version later than 20201015"?  I am
perfectly fine with using the full 8 digit timestamp.

MA

On Thu, Nov 18, 2021 at 4:24 PM Robert Goldman  wrote:

> On 18 Nov 2021, at 7:35, Eric Timmons wrote:
>
> > On 11/18/21 3:45 AM, Marco Antoniotti wrote:
> >> Sorry but I am missing something.
> >>
> >> It was said in this thread (don't remember who, apologies) that
> >>
> >> MMDD
> >>
> >> would work.  Will it?
> >
> > Yes. MMDD is currently a valid version string (assuming it's all
> > digits). Whatever we choose will allow a superset of what's already
> > allowed.
> >
> > -Eric
>
> That's true, but possibly stating the obvious: ASDF does not
> "understand" a version string like that.  So you can't say "any version
> since October 2020 will work." Getting something like that to work would
> be an exercise for the extension protocol.
>
> This actually might make a good test case for us to see if the proposed
> protocol (versioning method keyword initarg for defsystem) makes sense.
>
> R
>


-- 
Marco Antoniotti, Professortel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043http://dcb.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY

Re: Next steps

[Robert Goldman]

On 18 Nov 2021, at 7:35, Eric Timmons wrote:


On 11/18/21 3:45 AM, Marco Antoniotti wrote:

Sorry but I am missing something.

It was said in this thread (don't remember who, apologies) that

MMDD

would work.  Will it?


Yes. MMDD is currently a valid version string (assuming it's all 
digits). Whatever we choose will allow a superset of what's already 
allowed.


-Eric


That's true, but possibly stating the obvious: ASDF does not 
"understand" a version string like that.  So you can't say "any version 
since October 2020 will work." Getting something like that to work would 
be an exercise for the extension protocol.


This actually might make a good test case for us to see if the proposed 
protocol (versioning method keyword initarg for defsystem) makes sense.


R

Re: Next steps

[Marco Antoniotti]

Great, thanks!

On Thu, Nov 18, 2021 at 2:35 PM Eric Timmons  wrote:

> On 11/18/21 3:45 AM, Marco Antoniotti wrote:
> > Sorry but I am missing something.
> >
> > It was said in this thread (don't remember who, apologies) that
> >
> > MMDD
> >
> > would work.  Will it?
>
> Yes. MMDD is currently a valid version string (assuming it's all
> digits). Whatever we choose will allow a superset of what's already
> allowed.
>
> -Eric
>


-- 
Marco Antoniotti, Professortel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043http://dcb.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY

Re: Next steps

[Eric Timmons]

On 11/18/21 3:45 AM, Marco Antoniotti wrote:

Sorry but I am missing something.

It was said in this thread (don't remember who, apologies) that

MMDD

would work.  Will it?


Yes. MMDD is currently a valid version string (assuming it's all 
digits). Whatever we choose will allow a superset of what's already allowed.


-Eric

Re: Next steps

[Marco Antoniotti]

Sorry but I am missing something.

It was said in this thread (don't remember who, apologies) that

MMDD

would work.  Will it?

Cheers

Marco


On Thu, Nov 18, 2021 at 9:34 AM Didier Verna  wrote:

> Eric Timmons  wrote:
>
> > So to prevent misinterpretation of 3.4.0-1, ASDF could either promise
> > to always use something like alpha/beta/etc,
>
>   Then I suggest to also allow a, b, rc, and maybe p (for pre;
>   equivalent of release candidate). That should cover a lot of ground.
>
> --
> Resistance is futile. You will be jazzimilated.
>
> Lisp, Jazz, Aïkido: http://www.didierverna.info
>
>

-- 
Marco Antoniotti, Professortel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043http://dcb.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY

Re: Next steps

[Didier Verna]

Eric Timmons  wrote:

> So to prevent misinterpretation of 3.4.0-1, ASDF could either promise
> to always use something like alpha/beta/etc,

  Then I suggest to also allow a, b, rc, and maybe p (for pre;
  equivalent of release candidate). That should cover a lot of ground.

-- 
Resistance is futile. You will be jazzimilated.

Lisp, Jazz, Aïkido: http://www.didierverna.info

Re: Next steps

[Eric Timmons]

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 rpgold...@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.


-Eric

Re: Next steps

[Stelian Ionescu]

> On 17 Nov 2021, at 14:03, Stelian Ionescu wrote:
>
>>> On 17 Nov 2021, at 12:32, Stelian Ionescu wrote:
>>>

 You don't have to use the Quicklisp client to load dependencies, 
 just to fetch them (as a package manager).
 And for that, I think it should be always used this way.

>>> That only works if you are using the QL libraries unchanged. If you 
>>> need to patch or extend them, you need to set up a repo and handle 
>>> things yourself.
>>
>> This is definitely not true. You can configure ASDF pretty easily in 
>> such a way that you have a directory of local dependencies which 
>> override the ones in Quicklisp. I have lots of locally patched 
>> libraries and never had any problem with that.
>>
>
> What I mean is that Quicklisp doesn't handle this -- you fall back on 
> ASDF without QL.
> Specifically, if the library needs patching, you need to go out and find 
> it. AFAIK QL won't help you find the source and check it out, for 
> example.

Sure, if you need a fork that is outside Quicklisp you should fetch it yourself.

-- 
Stelian Ionescu

Re: Next steps

[Robert Goldman]

On 17 Nov 2021, at 14:03, Stelian Ionescu wrote:


On 17 Nov 2021, at 12:32, Stelian Ionescu wrote:



You don't have to use the Quicklisp client to load dependencies, 
just to fetch them (as a package manager).

And for that, I think it should be always used this way.

That only works if you are using the QL libraries unchanged. If you 
need to patch or extend them, you need to set up a repo and handle 
things yourself.


This is definitely not true. You can configure ASDF pretty easily in 
such a way that you have a directory of local dependencies which 
override the ones in Quicklisp. I have lots of locally patched 
libraries and never had any problem with that.




What I mean is that Quicklisp doesn't handle this -- you fall back on 
ASDF without QL.


Specifically, if the library needs patching, you need to go out and find 
it. AFAIK QL won't help you find the source and check it out, for 
example.


I found myself doing that enough that I just went directly to checking 
out the source, and skipping QL altogether.

Re: Next steps

[Stelian Ionescu]

>> You don't have to use the Quicklisp client to load dependencies, just to 
>> fetch them (as a package manager).
>> And for that, I think it should be always used this way.
> 
> I work on multiple projects which do not use Quicklisp at all, for a variety 
> of reasons which are not worth going into here, but which are unavoidable. 
> And I work on other projects which use Quicklisp for some dependencies, but 
> have other dependencies which cannot be in Quicklisp, again for a variety of 
> reasons.

Using one of the Quicklisp monthly distributions as a base does not preclude 
one from having local dependencies.

--
Stelian Ionescu

Re: Next steps

[Stelian Ionescu]

> On 17 Nov 2021, at 12:32, Stelian Ionescu wrote:
> 
>> 
>> You don't have to use the Quicklisp client to load dependencies, just to 
>> fetch them (as a package manager).
>> And for that, I think it should be always used this way.
>> 
> That only works if you are using the QL libraries unchanged. If you need to 
> patch or extend them, you need to set up a repo and handle things yourself.

This is definitely not true. You can configure ASDF pretty easily in such a way 
that you have a directory of local dependencies which override the ones in 
Quicklisp. I have lots of locally patched libraries and never had any problem 
with that.

--
Stelian Ionescu

Re: Next steps

[Erik Huelsmann]

>From semver.org:

Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta <
1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0

Regards,

Erik

On Wed, Nov 17, 2021 at 8: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 rpgold...@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...
>


-- 
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.

Re: Next steps

[Robert Goldman]

On 17 Nov 2021, at 13:31, Robert Dodier wrote:

On Wed, Nov 17, 2021 at 10:45 AM Robert Goldman  
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...

Re: Next steps

[Andreas Davour]

On Wed, 17 Nov 2021, Robert Dodier wrote:


On Wed, Nov 17, 2021 at 10:45 AM Robert Goldman  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).


Yeah, I find that one odd as well.

-andreas

--
"economics is a pseudoscience; the astrology of our time"
Kim Stanley Robinson

Re: Next steps

[Robert Dodier]

On Wed, Nov 17, 2021 at 10:45 AM Robert Goldman  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.

Robert.

Re: Next steps

[Robert Goldman]

On 17 Nov 2021, at 12:32, Stelian Ionescu wrote:

You don't have to use the Quicklisp client to load dependencies, just 
to fetch them (as a package manager).

And for that, I think it should be always used this way.


That only works if you are using the QL libraries unchanged. If you need 
to patch or extend them, you need to set up a repo and handle things 
yourself.


I was doing a lot of work on Allegro back in the day, and I found that 
many of the libraries I encountered only worked properly on SBCL.


At that point I started always working from source repos, rather than 
initially getting from QL and then having to backtrack to source repo 
when the library broke.


So I am definitely not going to make ASDF just the build system for 
Quicklisp!


I am *always* willing to cooperate with Xach or anyone else to make ASDF 
work smoothly with QL, but ASDF will never be just a QL module.

ASDF and versioning [was Re: Next steps]

[Robert Goldman]

That will work with the existing version comparison functions, yes, 
because it is still based on "string-encoding-of-number" comparison.



On 17 Nov 2021, at 12:34, Marco Antoniotti wrote:

I decided to switch to version numbers that are dates in MMDD 
format.


Looks like it would still work.

Marco

On Wed, Nov 17, 2021 at 7:19 PM Robert Goldman  
wrote:


Not sure what the syntax is, but I agree that holding to a fixed 
number of

arguments will be best, particularly for filtering out syntax errors.

On 17 Nov 2021, at 11:51, phoebe Goldman wrote:


On Nov 17, 2021, at 12:37 PM, Robert Goldman  
wrote:


version constraints like (:version "my-unstable-library" < 3) or
something like that *will* go in to ASDF.


Might I suggest the syntax:

(:version "my-lib" (:min "2")) ; equiv to (:version "my-lib" "3")
(:version "my-lib" (:below "3")) ; not :MAX, because this is an 
exclusive

bound
(:version "my-lib" (:range "2" "3")) ; inclusive lower, exclusive 
upper

bound

I believe it is both useful and aesthetically pleasing to keep the
:version form to exactly three elements.

cheers,
phoebe




--
Marco Antoniotti, Professortel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043
http://dcb.disco.unimib.it

Viale Sarca 336
I-20126 Milan (MI) ITALY

Re: Next steps

[Eric Timmons]

On 11/17/21 10:55 AM, Eric Timmons 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.


Sorry all, I didn't mean for this to descend into chaos.

I'll put together a summary of what may plan in this area is, along with 
a rationale. I'm a bit busy at the moment, but I expect I can email it 
out within the next couple days.


If nothing else, it'll give us something concrete to discuss.

-Eric

Re: 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 
, 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.

Re: 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 
, 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

Re: Next steps

[Marco Antoniotti]

I decided to switch to version numbers that are dates in MMDD format.

Looks like it would still work.

Marco

On Wed, Nov 17, 2021 at 7:19 PM Robert Goldman  wrote:

> Not sure what the syntax is, but I agree that holding to a fixed number of
> arguments will be best, particularly for filtering out syntax errors.
>
> On 17 Nov 2021, at 11:51, phoebe Goldman wrote:
>
>
> On Nov 17, 2021, at 12:37 PM, Robert Goldman  wrote:
>
> version constraints like (:version "my-unstable-library" < 3) or
> something like that *will* go in to ASDF.
>
>
> Might I suggest the syntax:
>
> (:version "my-lib" (:min "2")) ; equiv to (:version "my-lib" "3")
> (:version "my-lib" (:below "3")) ; not :MAX, because this is an exclusive
> bound
> (:version "my-lib" (:range "2" "3")) ; inclusive lower, exclusive upper
> bound
>
> I believe it is both useful and aesthetically pleasing to keep the
> :version form to exactly three elements.
>
> cheers,
> phoebe
>
>

-- 
Marco Antoniotti, Professortel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043http://dcb.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY

Re: Next steps

[Stelian Ionescu]

> On 17 Nov 2021, at 12:26, Stelian Ionescu wrote:
>
>> To guarantee an old working configuration you can simply point to the 
>> version of the Quicklisp distribution that it was last tested with. We 
>> should make it easy to specify that as metadata, and it would be much 
>> more useful than version constraints because ASDF is not blocking 
>> compilation (after all, even old software might very well work with 
>> newer version of the dependencies).
>
> This would be to assume that ASDF is only used in conjunction with 
> Quicklisp, which is not the case.

You don't have to use the Quicklisp client to load dependencies, just to fetch 
them (as a package manager).
And for that, I think it should be always used this way.

-- 
Stelian Ionescu

Re: Next steps

[Robert Goldman]

On 17 Nov 2021, at 12:26, Stelian Ionescu wrote:

To guarantee an old working configuration you can simply point to the 
version of the Quicklisp distribution that it was last tested with. We 
should make it easy to specify that as metadata, and it would be much 
more useful than version constraints because ASDF is not blocking 
compilation (after all, even old software might very well work with 
newer version of the dependencies).


This would be to assume that ASDF is only used in conjunction with 
Quicklisp, which is not the case.

Re: Next steps

[Stelian Ionescu]

>
> On 17 Nov 2021, at 11:08, Stelian Ionescu wrote:
> 
>>> 2. I *desperately* want to add version upper bounds. There is a real 
>>> problem of having someone change a library under one's system, and *pace* 
>>> Faré, sometimes one does not have the resources to handle updates to every 
>>> library in one's build chain.
>>> 
>> It's part of the social contract of open source that you get things for free 
>> but you need to stay up-to-date with your dependencies.
>> 
> That simply does not work for everyone, *definitely* including me. My company 
> can't afford to pay me to keep every piece of software lying around updated 
> with all of its dependencies. When a contract is done, I often can no longer 
> maintain related software. Similarly, I use a lot of software written at 
> universities as part of some research project that will eventually end. Other 
> examples abound. There's a *lot* of software out there that could be useful, 
> but that is not useful enough to the original author that they are going to 
> maintain it *ad infinitum*.
> 
> In such cases it's better that if we pull this stuff out of mothballs: (1) we 
> don't have to flail around trying to guess why it doesn't work any more and 
> (2) we can find an old working configuration.

To guarantee an old working configuration you can simply point to the version 
of the Quicklisp distribution that it was last tested with. We should make it 
easy to specify that as metadata, and it would be much more useful than version 
constraints because ASDF is not blocking compilation (after all, even old 
software might very well work with newer version of the dependencies).

> 
> In the best of all possible worlds, everything would always be up-to-date, 
> but that is not the world we live in -- or at least not the one that I live 
> in.
> 
>>> 3. I am not that worried that we will end up in the kind of mess that 
>>> concerns you: right now there are an enormous number of Lisp libraries that 
>>> don't even have version metadata *at all* . So if people want to use 
>>> expressive versioning in a sub-region of the lisp development ecosystem, 
>>> that is unlikely to cause the problems you see, and might help *some* of us 
>>> manage our dependencies.
>>> 
>> I am worried because once you make something easy, people will be tempted to 
>> use that feature. Authors aren't currently adding metadata because it's 
>> purely decorative and there's no real gain in maintaining that.
>> 
> On the contrary, *minimum* version constraints already exist. So it's not 
> true that metadata is purely decorative. It's because people are slobs, or 
> are not aware that the metadata are available.
> 
> --
> 
> The argument here is the same argument as Faré has made: all software should 
> always be maintained and kept-up-to-date. But Faré is a programming 
> superhero. I'm a mere mortal, but I *am* the ASDF maintainer, and at the end 
> of the day, I have decided that version constraints like `(:version 
> "my-unstable-library" < 3)` or something like that *will* go in to ASDF.
> 
> The worst that will happen is that someone will put in an overly-restrictive 
> version constraint. Given the state of the CL software ecosystem vs., e.g., 
> Python, I think it's quite unlikely that there will be a lot of overly-tight 
> restrictions out there. And the ability to have upper bounds meets an actual 
> need that is under-served.
> 


--
Stelian Ionescu

Re: Next steps

[Robert Goldman]

Not sure what the syntax is, but I agree that holding to a fixed number 
of arguments will be best, particularly for filtering out syntax errors.


On 17 Nov 2021, at 11:51, phoebe Goldman wrote:

> On Nov 17, 2021, at 12:37 PM, Robert Goldman  
wrote:


version constraints like (:version "my-unstable-library" < 3) or 
something like that will go in to ASDF.





Might I suggest the syntax:

(:version "my-lib" (:min "2")) ; equiv to (:version "my-lib" "3")
(:version "my-lib" (:below "3")) ; not :MAX, because this is an 
exclusive bound
(:version "my-lib" (:range "2" "3")) ; inclusive lower, exclusive 
upper bound


I believe it is both useful and aesthetically pleasing to keep the 
:version form to exactly three elements.


cheers,
phoebe

Re: Next steps

[Robert Goldman]

`version-satisfies` is *already* a generic function.  We will add some 
more capabilities to the built-in version in ASDF 3.4, but library 
authors will continue to be able to implement their own extensions.


On 17 Nov 2021, at 11:24, 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.

--
Resistance is futile. You will be jazzimilated.

Lisp, Jazz, Aïkido: http://www.didierverna.info

Re: Next steps

[Robert Goldman]

On 17 Nov 2021, at 11:08, Stelian Ionescu wrote:

 2. I *desperately* want to add version upper bounds. There is a real 
problem of having someone change a library under one's system, and 
*pace* Faré, sometimes one does not have the resources to handle 
updates to every library in one's build chain.



It's part of the social contract of open source that you get things 
for free but you need to stay up-to-date with your dependencies.


That simply does not work for everyone, *definitely* including me.  My 
company can't afford to pay me to keep every piece of software lying 
around updated with all of its dependencies.  When a contract is done, I 
often can no longer maintain related software.  Similarly, I use a lot 
of software written at universities as part of some research project 
that will eventually end.  Other examples abound.  There's a *lot* of 
software out there that could be useful, but that is not useful enough 
to the original author that they are going to maintain it *ad 
infinitum*.


In such cases it's better that if we pull this stuff out of mothballs: 
(1) we don't have to flail around trying to guess why it doesn't work 
any more and (2) we can find an old working configuration.


In the best of all possible worlds, everything would always be 
up-to-date, but that is not the world we live in -- or at least not the 
one that I live in.



 3. I am not that worried that we will end up in the kind of mess 
that concerns you: right now there are an enormous number of Lisp 
libraries that don't even have version metadata *at all* . So if 
people want to use expressive versioning in a sub-region of the lisp 
development ecosystem, that is unlikely to cause the problems you 
see, and might help *some* of us manage our dependencies.



I am worried because once you make something easy, people will be 
tempted to use that feature. Authors aren't currently adding metadata 
because it's purely decorative and there's no real gain in maintaining 
that.


On the contrary, *minimum* version constraints already exist.  So it's 
not true that metadata is purely decorative.  It's because people are 
slobs, or are not aware that the metadata are available.


--

The argument here is the same argument as Faré has made: all software 
should always be maintained and kept-up-to-date.  But Faré is a 
programming superhero.  I'm a mere mortal, but I *am* the ASDF 
maintainer, and at the end of the day, I have decided that version 
constraints like `(:version "my-unstable-library" < 3)` or something 
like that *will* go in to ASDF.


The worst that will happen is that someone will put in an 
overly-restrictive version constraint. Given the state of the CL 
software ecosystem vs., e.g., Python, I think it's quite unlikely that 
there will be a lot of overly-tight restrictions out there.  And the 
ability to have upper bounds meets an actual need that is under-served.

Re: Next steps

[Didier Verna]

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.

-- 
Resistance is futile. You will be jazzimilated.

Lisp, Jazz, Aïkido: http://www.didierverna.info

Re: Next steps

[Stelian Ionescu]

> On 17 Nov 2021, at 10:35, 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. Where 
>> they've already been implemented (Ruby, Python, Haskell), they've invariably 
>> lead to authors selecting overly restrictive contraints because there's no 
>> automatic way to determing the minimum version required from dependencies.
>> In turn, that makes even installing a package a nightmare because it often 
>> leads to unsatisfiable dependencies and having to (manually) backtrack until 
>> one can find a combination of compatible packages. The distribution model 
>> that Quicklisp has, by snapshotting the "world" once a month and ensuring 
>> that they all compile is much better so let's keep it that way.
>> 
>> 
>> If you think I'm exagerating, ask people that are familiar with the process 
>> of having to update a Ruby webapp (or a Jekyll blog with many plugins), or 
>> even a Python virtualenv-based server. Especially the Ruby community went 
>> down this rabbit hole to far that it's no wonder they were the first to 
>> adopt Docker back in the days: instead of subjecting users to the dance of 
>> "let's see if I can even get this to install" they ended up shipping a whole 
>> container as a workaround.
>> 
> I have mixed feelings about this:
> 
>  1. I agree that the situation in Python is a hot mess. I'm not sure how much 
> this is due to versioning messes as opposed to the excess specificity that 
> one gets from `pip freeze`, and another confound is the multi-headed horror 
> that is Python package construction and management.

Dependency freezing is yet another symptom of the problem: because the 
dependency hell makes it difficult to find a mutually compatible version set, 
authors make their own life easy by freezing deps, but that works poorly with 
the rest of the ecosystem.
The last time the problem of incompatible versions bit me I was trying to 
update my blog based on Octopress+Jekyll, and found that the latest release of 
each of the packages that I required - including plugins - couldn't be 
installed together. I had to manually backtrack by tweaking the versions (since 
rubygems didn't do that automatically), and it took me a few hours to converge 
on a working install. The year after I switched to Hugo.

>  2. I *desperately* want to add version upper bounds. There is a real problem 
> of having someone change a library under one's system, and *pace* Faré, 
> sometimes one does not have the resources to handle updates to every library 
> in one's build chain.

It's part of the social contract of open source that you get things for free 
but you need to stay up-to-date with your dependencies.
If a library changes too often, it's a social problem and shouldn't be 
addressed with technical means: talk to the author and ask to keep 
backwards-compatibility for a while longer or remove/replace the dependency.
I cannot stress enough how much better the Quicklisp monthly distribution model 
is compared to what I see anywhere else. Once you open this Pandora's box there 
will be no going back (are you open to removing the feature from ASDF if it 
goes bad ?).

> It's always better for the poor user to see an error message saying that 
> something won't work because of a library update, instead of seeing some kind 
> of horrible mess with no clue where to look.
> 
>  3. I am not that worried that we will end up in the kind of mess that 
> concerns you: right now there are an enormous number of Lisp libraries that 
> don't even have version metadata *at all* . So if people want to use 
> expressive versioning in a sub-region of the lisp development ecosystem, that 
> is unlikely to cause the problems you see, and might help *some* of us manage 
> our dependencies.

I am worried because once you make something easy, people will be tempted to 
use that feature. Authors aren't currently adding metadata because it's purely 
decorative and there's no real gain in maintaining that.

--
Stelian Ionescu

Re: Next steps

[Robert Goldman]

On 17 Nov 2021, at 10:35, 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. Where 
they've already been implemented (Ruby, Python, Haskell), they've 
invariably lead to authors selecting overly restrictive contraints 
because there's no automatic way to determing the minimum version 
required from dependencies.
In turn, that makes even installing a package a nightmare because it 
often leads to unsatisfiable dependencies and having to (manually) 
backtrack until one can find a combination of compatible packages. The 
distribution model that Quicklisp has, by snapshotting the "world" 
once a month and ensuring that they all compile is much better so 
let's keep it that way.


If you think I'm exagerating, ask people that are familiar with the 
process of having to update a Ruby webapp (or a Jekyll blog with many 
plugins), or even a Python virtualenv-based server. Especially the 
Ruby community went down this rabbit hole to far that it's no wonder 
they were the first to adopt Docker back in the days: instead of 
subjecting users to the dance of "let's see if I can even get this to 
install" they ended up shipping a whole container as a workaround.


I have mixed feelings about this:

1. I agree that the situation in Python is a hot mess. I'm not sure how 
much this is due to versioning messes as opposed to the excess 
specificity that one gets from `pip freeze`, and another confound is the 
multi-headed horror that is Python package construction and management.


2. I *desperately* want to add version upper bounds. There is a real 
problem of having someone change a library under one's system, and 
*pace* Faré, sometimes one does not have the resources to handle 
updates to every library in one's build chain.  It's always better for 
the poor user to see an error message saying that something won't work 
because of a library update, instead of seeing some kind of horrible 
mess with no clue where to look.


3. I am not that worried that we will end up in the kind of mess that 
concerns you: right now there are an enormous number of Lisp libraries 
that don't even have version metadata _at all_ . So if people want to 
use expressive versioning in a sub-region of the lisp development 
ecosystem, that is unlikely to cause the problems you see, and might 
help *some* of us manage our dependencies.


Cheers,
R

Re: Next steps

[Stelian Ionescu]

> 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. Where they've 
already been implemented (Ruby, Python, Haskell), they've invariably lead to 
authors selecting overly restrictive contraints because there's no automatic 
way to determing the minimum version required from dependencies.
In turn, that makes even installing a package a nightmare because it often 
leads to unsatisfiable dependencies and having to (manually) backtrack until 
one can find a combination of compatible packages. The distribution model that 
Quicklisp has, by snapshotting the "world" once a month and ensuring that they 
all compile is much better so let's keep it that way.

If you think I'm exagerating, ask people that are familiar with the process of 
having to update a Ruby webapp (or a Jekyll blog with many plugins), or even a 
Python virtualenv-based server. Especially the Ruby community went down this 
rabbit hole to far that it's no wonder they were the first to adopt Docker back 
in the days: instead of subjecting users to the dance of "let's see if I can 
even get this to install" they ended up shipping a whole container as a 
workaround.

-- 
Stelian Ionescu

Re: Next steps

[Eric Timmons]

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.


Another 3.3 release might be in order to get !189 out (although maybe 
it's not that important; I'm honestly surprised by how few complaints 
I've seen about it).


And if there's another 3.3 release, I'd like to nominate !194 for 
merging beforehand. !195 is also a bug fix, but the bug has existed for 
almost as long as the feature has been around. So perhaps delaying it 
for 3.4 is more prudent.


On 11/17/21 9:14 AM, Robert Goldman wrote:
Then, if we want to back patch, we can create a |stable| branch and 
cherry-pick onto that (using |maint| would create too much potential for 
confusion).


I'd suggest something like 3-3-stable instead (or really anything that 
gets the 3.3 in there). The branch can be deleted when 3.4 is released 
so we're not supporting more than one release at a time. I still think 
having a "stable" branch whose history changes isn't a great idea.


-Eric

Next steps

[Robert Goldman]

The next item to merge is Alberto's !192. This is new functionality, 
rather than a bug fix, so I am considering adding a `main` branch, 
retiring `master`, and moving most activity there, with an eye to 
getting the first 3.4 release underway. That would permit me to start 
merging a number of things that add new capabilities that don't seem 
like a patch version.


Alternatively, we could just keep `master`, but it seems like that is 
becoming old standard practice, so changing to `main` would comply with 
the new de facto standard established by GitHub.


Then, if we want to back patch, we can create a `stable` branch and 
cherry-pick onto that (using `maint` would create too much potential for 
confusion).


Thoughts?