November 2021 - asdf-devel - mailman3.common-lisp.net

Version specifiers and constraints
by Eric Timmons 23 Nov '21

23 Nov '21

Attached is a patch to ASDF's documentation that describes what I plan to implement to allow ASDF to have both customizable version specifiers and more expressive version constraints. I would appreciate concrete feedback on this proposal. Additionally, this diff exists on MR !169 if you would prefer to give feedback that way. If you do, please mostly ignore the non-documentation changes. The other changes were made quite a while ago and don't take into account some of the recent feedback I've received. Some notes: To support extensible version specifiers, I started with Didier's approach (first discussed at <https://mailman.common-lisp.net/pipermail/asdf-devel/2015-June/004698.html>, I believe). However, that approach required a non-standard system class if you wanted to extend the version specifier. That seemed rather heavy-handed, so I moved to an approach where you can specify a :version-class in your defsystem. This should also make it composable with custom classes. However, if you foresee issues with that, we can change it back. One of the version classes provided by UIOP is called semantic-version. It implements only the semver grammar and ordering relationships. It does not implement any sort of constraint on major versions matching or the like (note that such a thing is not even required by the semver spec!). However, I realize that "semantic version" can be a loaded term, so I'm happy to discuss changing the name of the class if anyone has a workable idea. The other version class is called default-version. Currently it's a subclass of semantic-version. However, given Robert's recent suggestion to limit the pre-release segment to alpha/beta/rc and an optional integer, that could be changed. In fact, we could implement Didier's preferred grammar as well, where X.Y.ZaW would be equivalent to X.Y.Z-alpha.W and the same with b/beta and rc/rc. The attractive thing about that is it means ASDF's defaults would likely cover the vast majority of version grammars developers would want to use. I'm particularly interested in feedback on the :compatible-versions argument to defsystem. I don't think any other build tool I have experience with provides such a thing. However, it seems like an elegant way to address the common complaint that more expressive version constraints encourage a system consumer to block versions of their dependencies that haven't even been released yet. -Eric

1 0

Next steps
by Robert Goldman 19 Nov '21

19 Nov '21

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?

11 47

Re: Next steps
by Stelian Ionescu 17 Nov '21

17 Nov '21

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

1 0

Re: Next steps
by Robert Goldman 17 Nov '21

17 Nov '21

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 <rpgoldman(a)sift.info> > 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

2 2