Thoughts on versioning?

[abathur]

I'm getting my ducks in a row to submit a nixpkgs expression for bashup.events. First, I want to check in on some versioning issues. (Nix's packaging instructions get a little nonsenical when combined with a package that doesn't have an official version number but does have multiple ~release branches.)

I think (caveat: this is the first first time I'm writing a Nix package for submission) the usual package name--with a single branch and no official version number--would be like bashup-events-unstable-2019-07-27 (from a template like: <package name>-[<unstable>-<date-of-commit>|<significant/stable_parts_of_version_number>]). Unfortunately, these instructions produce the same package name for both the bash 3.2+ and 4.4+ implementations.

I don't mind inquiring with them about how to name/version it, but first I wanted to see if you have any plans (like tagging official versions or starting a 5.x+ branch) that should factor in.

For some additional context:

• Nix packages (and dependencies on them) are often declared via a symbolic name that leaves out insignificant precision (i.e. python2, python27, python3, python36, python37, python38). In this case it could produce version-specific names like bashup-events32 and bashup-events44. (FWIW: bash 4.4 is bash and bash 5.0.x is bash_5--don't ask me about the underscore... AFAIK it is not "correct", but I'll let PR review sort that out...)

• We're supposed to use a bare name (i.e. bashup-events) when there's just one obvious primary package version. I don't think the docs for bashup.events imply an obvious primary package version, but in a Nix-specific context I'm at least tempted to call bashup-events 4.4+ the obvious choice because Nix already depends on bash 4.4 and will be moving up to 5.x soon.

[pjeby]

I would suggest the python-style versioning. The main and 4.4 branches are both valid and useful things to have, as each has specialty semantics that are useful in different contexts. I don't really plan to deprecate the 3.x version, even though it may move off the main branch at some point in the future. And if at some point they do have official versions, they'd be something like bashup/events-3 1.0 and bashup/events-4 1.0. :)

The differences in their implementations mean that the 3.x version can have "local events" and iterates over events in sorted order, whereas the 4.x version is faster but doesn't have a guaranteed order of event iteration. These differences in semantics may be relevant for some use cases, even if you're only actually supporting bash 4.4 or 5.

TBH, though, it mostly isn't expected that anyone would ever install bashup events as a systemwide script, vs. just including it within your own program. All of the bashup and dirtsimple packages that use it simply embed it, and that's why the license is CC0-based: you can just copy and paste it into your scripts without needing any additional license documentation. (That's also why the code style is so... shall we say, "compact".)

(To put it another way: bashup/events is more like a static library to be linked into shell scripts than it is a dynamic library to be called by them. It is more like a -dev or -devel package, in other words.)