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