3 ms·

I don't really consider semver to be in conflict with build numbers or version numbers for marketing purposes. My favored scheme is roughly like so. Automatica

I don't really consider semver to be in conflict with build numbers or version numbers for marketing purposes. My favored scheme is roughly like so. Automatically assign a build number to every build for tracking purposes. Assign a semver number to every version you publish in order to give some concise signaling to operations folks and technical consumers about how the version behaves compared to the previous one(s). And, when applicable, assign a more creative version number for marketing purposes. I've always liked year-based numbering schemes for that purpose. It's immediately meaningful, and encourages staying up-to-date by giving a reminder that you're still on a version that came out 4 years ago.

specialist 6y ago
Correct. In every way. Deming process people call this "one way flow" of information. Paraphrasing, mostly to continue my rant: Versions are just labels (tags, aliases) you share with clients, users. Semver is no worse than any other scheme. And fretting about semver gives scrum masters something to do. Build numbers are used for internal processes. Like the "found", "fixed", "closed" fields that QA tools should have (but rarely do). As you said, version is annointed AFTER an artifact is accepted, moments before release. Like an imprint. (For all workflows prior to "Test Into Prod", so ymmv.) Then everyone can also precognitively divine a future version, so stuff like press releases can be front loaded. Genius! Few things drive me more nucking futts than teams which predetermine version before attempting a build. Oops, build failed. Manually increment semver. Try again. Rinse, lather, repeat. Then ferret all wiki references to semver and update those JIRAs. Trying to explain this to noobs is harder than advocating using knives for cutting to someone who's only ever seen spoons. People get it when they see it, but can't imagine it, so the push back is exhausting.
- mumblemumble 6y ago
  Not just noobs. It's even more exhausting to try and have this sort of conversation with someone who's been doing it that way for 20 years, and never known anything else.

specialist 6y ago

Correct. In every way. Deming process people call this "one way flow" of information. Paraphrasing, mostly to continue my rant: Versions are just labels (tags, aliases) you share with clients, users. Semver is no worse than any other scheme. And fretting about semver gives scrum masters something to do. Build numbers are used for internal processes. Like the "found", "fixed", "closed" fields that QA tools should have (but rarely do). As you said, version is annointed AFTER an artifact is accepted, moments before release. Like an imprint. (For all workflows prior to "Test Into Prod", so ymmv.) Then everyone can also precognitively divine a future version, so stuff like press releases can be front loaded. Genius! Few things drive me more nucking futts than teams which predetermine version before attempting a build. Oops, build failed. Manually increment semver. Try again. Rinse, lather, repeat. Then ferret all wiki references to semver and update those JIRAs. Trying to explain this to noobs is harder than advocating using knives for cutting to someone who's only ever seen spoons. People get it when they see it, but can't imagine it, so the push back is exhausting.

mumblemumble 6y ago
Not just noobs. It's even more exhausting to try and have this sort of conversation with someone who's been doing it that way for 20 years, and never known anything else.