* Do users declare a dependency on "= 37", or ">= 37"? (Or do they have the option of either?)
* How do you push backwards-compatible changes like bugfixes? Is the rule that every new release is a new version number?
* If you do the >= thing, do you automatically take the newest compatible dependency or the oldest possible one (vgo-style)? Do you run tests on reverse dependencies when dependencies are updated?
* Are you allowed to have diamond dependencies, e.g., A depends on B and C, B depends on AdminTools 37, and C depends on AdminTools 38? Do you resolve that with a single copy of AdminTools, or two?
Looking at the example CalVer projects: Ubuntu follows this model because it's the model of basically all UNIX distributions, that a particular command name doesn't change meaning / API without either a deprecation cycle or an explicit action from the sysadmin. If a command changes incompatibly (e.g., Python 2 to Python 3), it gets a different name (e.g., /usr/bin/python to /usr/bin/python3). If a library changes incompatibly, it either uses symbol versioning infrastructure to provide old and new versions of the function (e.g., fmemopen@GLIBC_2.2.5 is now provided by libio/oldfmemopen.c, and the fmemopen@GLIBC_2.22 implementation, which fixes tons of bugs and drops questionable features, is only visible to programs compiled on a system with glibc 2.22 or newer), or the library itself has a new filename (e.g., at some point libcurl.so.3 became libcurl.so.4). Therefore, code that compiled and ran fine on, say, Ubuntu 16.04 should generally be expected to compile and run fine on Ubuntu 18.04, or less commonly, not run at all with a clear error up front about the specific missing functionality.
Twisted, youtube-dl, and pytz follow a similar model. Code written against them years ago should generally continue to work; the version number provides information on new features, not on deprecations.
Teradata UDA is different, but it follows the underlying CalVer philosophy of breaking changes being something to avoid. (But it uses a year and month to indicate an API compatibility level, which isn't how the rest of the CalVer projects use dates.)
So the answers to my bullet points for CalVer are generally ">=", "Rename the functionality, do not ever redefine an existing name", "Newest compatible dependency is fine and you should definitely have integration tests," and "Diamond dependencies to different versions aren't a problem, diamond dependencies to different names e.g. libcurl.so.3 and libcurl.so.4 are discouraged but should work".
"= 37".
> How do you push backwards-compatible changes like bugfixes? Is the rule that every new release is a new version number?
A backwards-compatible change gets a new version number, like any other change.
The system does actually let you use version numbers like "37.1", but it doesn't assign any meaning to them. They're all opaque symbols, really. You could just as well have versions "first", "new", "improved new", "new new", "new new (final)", "new 2", etc.
> If you do the >= thing, do you automatically take the newest compatible dependency or the oldest possible one (vgo-style)?
We don't use ">= 37".
> Do you run tests on reverse dependencies when dependencies are updated?
Oh god no.
Personally, when i'm upgrading a library, it will usually be to address a need of a particular consumer, and i will develop the upgrade and the change to the consumer in concert. So that's sort of testing it with a reverse dependency, but only one.
> Are you allowed to have diamond dependencies, e.g., A depends on B and C, B depends on AdminTools 37, and C depends on AdminTools 38?
You can express a dependency like that, and if there is a conflict, the package manager shouts and you and stops. You then have to write something like "no really, use version 38" to persuade it to work.
> Do you resolve that with a single copy of AdminTools, or two?
A single copy.
To my mind, these are all questions about our package management tool, not our versioning scheme.
If it spreads the idea that there are several ways to do versioning, and not only semver, and it gives a proper rationale, I'm ok with that. (server.org might be difficult to register though).
CalVer is just a pattern with a name so you can talk around about why Ubuntu uses year.month as version, and some ideas on when it is good to use it or not.