I like semver. I work as a systems folk, and I end up neck deep in other peoples' dependencies more often than I would like. For libraries, semver is pretty good.
That said, I've run into a cult of programmers who see semver as the best thing next to Jesus coming back for solving all their problems. And they go to alllll the meetings. Some things I've seen:
The key idea around semver is around choice. If your users have the ability to actively choose what version of your software they're using, it works. But large amounts of software is foundational, in that it needs to keep working for a long time to allow for progress to be made above it. This is common in infrastructure, where we are so low in the stack the ripple effects of changes end up costing an enormous amount.If your users don't have a choice as to how they consume your software (its behind an API, its a hidden script that produces a report, etc), dont break your API. Make a new thing, name it something else, figure out the migration that makes sense for you and your users. And if you learn to communicate major releases within the context of your users, theres probably a good chance you could use that knowledge to better communicate features and bugfixes than trying to encode it into a single number that's an incidental string to your package manager.
Do your users even care what version of your software they're using? Or do they just want it to work?
Another small note, when dealing with automated CI/CD pipelines, the developer must always specify the semver to the automation. Semver throws a complexity wrench in what would otherwise be straight-forward automated releases. Determining what changed at an interface level in the best case requires scraping contrived commits or doc files in the repository, which must be reliably updated by every developer (lol). There is a way to programatically compare an interface and bump a semver string automatically, but down that path lies Swagger diffing and RAML and "Codeless" startups, and ahhh good luck with that.
Are you releasing software to other developers who are making concious choices on when and how to depend on your software, as part of a dependency tool (like ruby gems) across an organizational boundary? Then maybe use semver. Update your CHANGELOG and please set some releases in Github so we have a chance to understand which ways up.
You should probably just automatically generate the version based on source code for the benefit of everyone involved. So what would the best way to do that look like?
When I'm digging around in whatever new wibblywobbly landed on my desk that day, I'm going to need a vague idea of what generation of code I'm working on, and most importantly a way to trace that specific species of wibblywobbly through the various artifact stores (they keep making more of them?) and eventually back to whichever repository it crawled out of.
Without outside information, when trying to communicate a feature or a bugfix, whats easier, "/foo was added in version 27" or "/foo was added in 2008.02.28" ?
Who's date? The date the customer sees it or the date the developer wrote it? Hopefully you have a continuous deployment pipeline in place, in which the customer gets an evergreen version without thinking about it, in which case our versioning should be developer centric.
#!/usr/bin/env bash # -- samver # -- in a git repo, spits out a goodly version if date --version &>/dev/null; then # GNU echo $(date --utc --date="$(git show -s --format=%ci)" +%Y%m%d%H%M)-$(git rev-parse --short HEAD) else # BSD echo $(date -u -j -f %s $(git show -s --format=%ct) +%Y%m%d%H%M)-$(git rev-parse --short HEAD) fi
What do I do if I commonly have multiple commits in the same minute?
What do I do if I commonly have multiple commits in the same second?
What do I do if I have to use something insistent on semver?
Error: Error parsing version segment: strconv.ParseInt: parsing "20191025125407": value out of range
Should I rethink the semantic overloading of strings in other contexts, like filenames?
-- Sam Rees, Computer Plumber Chicago, IL