> 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
