Re: Versioning

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,

Re: Versioning

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

Versioning

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 rpgold...@sift.info wrote: I favor something like this

Re: Next steps

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

Re: Next steps

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

Re: Next steps

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

Re: Next steps

>> 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

Re: Next steps

> 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

Re: Next steps

>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

Re: Next steps

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

Re: Next steps

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,

Re: Next steps

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

Re: Next steps

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

ASDF and versioning [was Re: Next steps]

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

Re: Next steps

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

Re: Next steps

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

Re: Next steps

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

Re: Next steps

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

Re: Next steps

> 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

Re: Next steps

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

Re: Next steps

> > 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 >>>

Re: Next steps

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

Re: Next steps

`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

Re: Next steps

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

Re: Next steps

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

Re: Next steps

> 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

Re: Next steps

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

Re: Next steps

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

Next steps

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