17:02:55hexologyi see, i didn't realize manual work was being done to validate that they all build together
17:03:19hexologyby comparison, npm, pypi, etc. would be "rolling release" where the author can publish a new version at any time
17:03:20Xachit's pretty automated, but there's a bit of manual work to plug the failure logs into github or other bug report systems.
17:03:42Xachthere are advantages to rolling releases too - i don't mind if people don't like how quicklisp works, there are different ways to do things.
17:04:00hexologyit's not that i don't like it, it's that it's very unusual for a programming language package manager
17:04:17XachIt helps that Lisp has so few libraries and so little activity!
17:04:49hexologywhat if there's a bug and a developer wants to publish a quick fix? do people just have to install from git, or is it case-by-case where you might do a 2nd release?
17:05:58Xachhexology: there are a few options for the user. 1. don't update to the new dist 2. override with a local version from git or whatever. I rarely, rarely make a quick new release of everything - I've done it when slime crashed on startup, once, but fewer than 5 times in 10 years.
17:10:26hexologyso there's no "technical" reason why one couldn't make something like npm for lisp packages, it was just a design decision
17:10:33hexologyi haven't used ultralisp at all, i was wondering about it
17:12:05hexologybased on the website, it looks like ultralisp is also versioned in "releases", but maybe those releases are automatic whenever a package is updated
17:12:12hexologyso more like rolling. i'll do some reading
17:12:31jmercouriskeep them doggies rolling rawhide!