drym-org
Docs for v5
Summary of Changes
A few more documentation updates, including:
- crosslink in relevant places to the
qi/listmodule - document our release practices for users, with guidance on getting different kinds of behavior that we might want
Public Domain Dedication
- [x] In contributing, I relinquish any copyright claims on my contribution and freely release it into the public domain in the simple hope that it will provide value.
(Why: The freely released, copyright-free work in this repository represents an investment in a better way of doing things called attribution-based economics. Attribution-based economics is based on the simple idea that we gain more by giving more, not by holding on to things that, truly, we could only create because we, in our turn, received from others. As it turns out, an economic system based on attribution -- where those who give more are more empowered -- is significantly more efficient than capitalism while also being stable and fair (unlike capitalism, on both counts), giving it transformative power to elevate the human condition and address the problems that face us today along with a host of others that have been intractable since the beginning. You can help make this a reality by releasing your work in the same way -- freely into the public domain in the simple hope of providing value. Learn more about attribution-based economics at drym.org, tell your friends, do your part.)
I've incorporated your suggestions @benknoble , and also made the wording less controversial. It's still not perfect but definitely an improvement.
I think Jay McCarthy is the first person I heard talk about versioning as primarily a social issue best solved socially not technologically. That idea really surprised me at first.
The biggest issue is, do you want other people/software to use/depend on you? If you don't, because it's still alpha/beta WIP, that's simple. Just make sure people know that, and they can proceed accordingly. Probably they can't/won't use your stuff in packages that they want to offer as stable and dependable. Transitivity.
If someday/maybe you do want something to be used by other people, in software they in turn offer to others as stable... then you're kind of entering into a bargain. The exact nature of the bargain, is up to you and them. There are different ways to handle it.
Anyway I think there are two main kinds of changes to consider:
-
Backward compatible or not ("breaking" changes). You probably can't tell people to use your stuff, then keep breaking their use of it. You probably need to keep it available indefinitely. You can say that some subset won't improve, anymore, but you can't say it will disappear. It's fine to advise people to depend on a git commit/tag, if that's how you want to do it.
-
New things. In a lang like Racket, I'd suggest just bumping the plain old version number for people's
depsandraco pkg updateto refresh. But just for that. Beyond that, they can do things like try todynamic-requireyour new function, and proceed accordingly depending on whether it's available. (I do this all the time in Racket Mode, to optionally use things in newer versions of Racket.)
Personally, I feel that SemVer (or not) is beside the point. In chaotic package ecosystems with lots of bad actors, SemVer is probably a way for package users to feel some control or stability. Horse left barn long ago; cope as best you can. But of course it's trying to define rules for what should be basic human courtesy (the social dimension), which is something we programmers tend to do. :smile:
I think Jay McCarthy is the first person I heard talk about versioning as primarily a social issue best solved socially not technologically. That idea really surprised me at first.
It might have been Greg and Sid that first exposed me to one of my new mantras[^1]: technology doesn't solve social problems.
Which is a really shorthand way of saying what Greg spelled out, for lots of different cases, and has a lot of nuance—some people think I mean that better food distribution systems wouldn't alleviate food insecurity, for example, when I really mean that food insecurity should be tackled primarily on the social side, possible using technology as a tool in the solution. The curse of shorthands is nuance lost, as anyone who reads or writes about "best practices" should know ;)
[^1]: This was several years ago, and I have a vague memory of seeing it on the Racket Discourse, but I don't recall and I didn't dig for it.
It seems that dependency versioning problems all stem from using one name to refer to two different things. Thinking of you, @zyrolasting. -- @countvajhula
I now recall Sage saying something about layering or meshing code together, so maybe there's some "there" there. -- @benknoble
Denxi's input overriding example seems relevant here. The words "input", "output", "package", and "transaction" use Denxi's definitions, but it is true that Denxi resolves name conflicts.
it would be great to include a section here on using Qi with Denxi, Sage, if that's possible today -- @countvajhula
You know how Ruby has rvm and Node.js has nvm? These programs protect the user from versioning details. Say Qi gets a qvm. You have to ask the user to install a thing to install a thing, but they might prefer to do that than understand the underlying versioning rules.
A version manager must be stable, which works nicely with Racket package catalogs. So you'd say raco pkg install qvm , then (maybe) raco qvm install <version> <collection> to bind a set of collection paths to a set of modules known to work together. <version> can be whatever you want, since your source does not have to be Racket's package catalog at that point (EDIT: <collection> likely defaults to qi or qi2 depending if your <version> scheme cares to make that distinction). If you use Denxi to do this, then qvm might be a Denxi launcher. One would use more of Denxi when you want to use the same <collection> for different values of <version>.
Does this fit what's being discussed?
