mirror of
https://github.com/semver/semver.git
synced 2026-03-22 22:20:28 -05:00
Advice on keeping track of changes requiring increment to maj/min/patch numbers #203
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#203
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @cvolpe on GitHub (Nov 13, 2015).
Before I adopt something ad-hoc, does anyone have any best practices for ensuring that semver is being followed accurately? I was thinking something along the lines of a header file that contained the three versioning numbers, along with three flags indicating whether any change had been made that would necessitate bumping any of those numbers. Whenever I check something in, I determine whether any of those three numbers needs to change. (If cosmetic, or performance improvement only, nothing needs to change.) If anything needs to change, I set the corresponding flag to true, unless a "coarser grained" flag is already set to true, and set the "finer grained flags" to false. When it's time to release, Whichever flag is set dictates which number to bump, and I manually bump that number. I realize this seems like a silly question, but is there a better way to do this?
@LinusU commented on GitHub (Nov 11, 2016):
That is quite an interesting way...
Where I'm currently working we are prefixing each commit with an emoji that determines the bump level.
💥 - breaking
🎉 - feature
🐛 - bugfix
🔥 - cleanup/performance (we use this to make a patch bump without specifically fixing a bug, as far as I understand the semver spec, you are not allowed to release these. But we want to get it out as soon as possible so that we can know if something is wrong with it)
🌹 - no bump
We also have a "bot" that automatically releases a new package to npm every time a PR is merged into master, with the appropriate versioned bumped. (the version bump commits are prefixed with 🚢)
@jwdonahue commented on GitHub (Dec 9, 2017):
@cvolpe,
Stop putting version numbers in your header files for one. If you fix a bug somewhere in your code, the patch number has to be bumped, but if you do that in a header file, then everything that depends on that file has to be recompiled (potentially a breaking change for some of your customers). This process does not scale. Move the version number to a version.txt or versions.txt and add a function to your API that returns a SemVer string or a struct/class with each of the components in it or accessors for them. If anything needs the version at run-time, it can access those. That should help shorten your build times a bit and get you closer to full compliance with SemVer.
When you submit changes to your revision control system (you do have an RCS yes?), make sure you add one of the following identifiers to the start of your check-in message/comment:
Then when you run your build (assuming it succeeds!), dump the RCS logs since the last SemVer version stamp was applied and search for those identifiers. Whichever is the highest one you find in the set, that's the version level to bump. Read/parse the version.txt file, bump the appropriate value, zero any of the lower ones and write it back out to the file. You can probably find scripts online that can help you with some of this. Now apply a new SemVer label to the commit hash you just built and include an appropriate prerelease tag.
Package your bits based on that last label. When your test pass against that version indicates there's no bugs, you can update the previous label or add a new one to the commit hash that has a different prerelease label on it.
When it is time for a release, run your publish automation. That should create a new package from the same commit hash and may remove the prerelease tag, depending on if your intent is to publish a prerelease or a release.
Have beer and pizza! Cheers!
Unless you have further questions, please close this issue at your earliest possible convenience.
@jwdonahue commented on GitHub (Oct 8, 2018):
@cvolpe,
You can find tools to assist with this process here on https://github.com/search?q=semantic+commits
Unless you have further questions, please close this issue at your earliest possible convenience.
@cvolpe commented on GitHub (Dec 5, 2018):
Thanks, Gentlemen. Sorry for the delay. I must have missed the email notifications that comments had been posted.