mirror of
https://github.com/semver/semver.git
synced 2026-07-10 19:50:47 -05:00
[GH-ISSUE #470] Versioning Patches #3059
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#3059
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 @valecarlos on GitHub (Oct 11, 2018).
Original GitHub issue: https://github.com/semver/semver/issues/470
In the following scenario:
What should be the version number for this release?
@jwdonahue commented on GitHub (Oct 11, 2018):
From what I can gather of your build/publication processes, your publication history is:
1.0.0 // Internal publication (early adopters, testers)
1.0.0 // External publication
1.0.1 // Internal publication
1.0.2 // Internal publication
Why wouldn't your next internal publication be 1.0.3? You're versioning internal or limited publications, why would anything be any different? If you're really asking "is it okay to skip versions, that is publicly release 1.0.0 followed by 1.0.3?", the answer is yes.
It makes sense that you would be applying the appropriate version string at the packaging step. Many organizations have a pipeline through which a package progresses through releases to increasingly wider audiences. The published package doesn't change, but it might not ever make it to the generally available (GA) channel(s).
I would recommend that you beef up your unit tests, which should happen between the build and packaging steps. If you're not getting 100% product code coverage from your unit tests, then you'll be packaging many more builds that aren't ready for GA.
There are lots of other viable processes that can be deployed, some of which do not bump the version until the final GA publication of any given build. These usually delay packaging to that final step (weak) or repackage an internally circulating package with new version (strong). Some organizations simply use the build number for a version string internally and SemVer for GA publications only.
You are free to change your processes at any time, but once you have applied a version string to a package, that string should never be used again. No two packages should ever have the same version string and different content. This implies that you have already burned the first two patch level version strings, so even if your processes change to apply the version string at the GA release only, your next version should be 1.0.3. What happens after is up to you.
@jwdonahue commented on GitHub (Oct 11, 2018):
@valecarlos , unless you have further questions, please close this issue at your earliest possible convenience.
@valecarlos commented on GitHub (Oct 11, 2018):
thanks for your answer. Yes, unit testing and integration testing are in place and are quite important, but fixes done on 1.0.1 and 1.0.2 have not been reviewed/accepted by PMs and/or POs, so isn't it confusing to have a live version 1.0.3 that in reality, does not include changes done for 1.0.1 and 1.0.2?
@jwdonahue commented on GitHub (Oct 11, 2018):
No, I don't. You're going to have 1.0.0 and 1.0.3 generally available, not 1.0.1 or 1.0.2. You'll probably want to merge everything eventually, and release that as 1.0.4. The public just isn't ever going to see 1.0.1 and 1.0.2, unless you already have beta releases and those should be tagged with prerelease tags anyway.
Your process is what it is. If your personnel don't understand it, educate them or change it. The salient points to remember here are, there can only ever be one set of bits for a given version string. Never reuse a version string to label another package, once it's been used. Your process involves creating packages with version numbers on them and putting those into a pipeline that might end in a public release. Apparently you think it's okay to short-circuit the pipeline to release hot-fixes, so you'll get things out of order on occasion.
Document what you do and then do what you say. If you want to avoid this kind of scenario in the future, change your processes. It's okay to have the same set of bits with two different version strings, so you can build packages for internal consumption with a build number or prerelease tag and then when you decide a particular package passes the bar, you give it a new version and release that.
@jwdonahue commented on GitHub (Oct 12, 2018):
Ever since I started VersionMeta and VersionSchema, I have leaned more towards the build number variety of version string for internal releases. Even those can have prerelease tags and metadata attached to them. Internal releases would have a different VersionMeta tag on them than the external releases. The semantics and syntax for each are defined in the reference VersionSchema. I am working on some example tooling.
I would welcome some feedback if you'd care to take a look.
@jwdonahue commented on GitHub (Oct 12, 2018):
@valecarlos , unless you have further questions, please close this issue at your earliest possible convenience. Thank you.
@jwdonahue commented on GitHub (Oct 17, 2018):
@valecarlos, do you need any more assistance with this?
@valecarlos commented on GitHub (Oct 17, 2018):
sorry for the delay, reading up your replies, I you make a point between internal and public releases, the case for us is that with CI, potentially any internal release could be a public release (of course this is not a fantasy world and that doesn't happen quite like that); but, the point here is that when a Hot fix comes, and we need to patch our public version 1.0.0 we were having trouble naming this new version.
The issue is actually naming the version, but keeping track of where this new version is coming from, and what it includes and does not include.
having that in mind, we have opted to name our hot fix versions like: 1.0.0.1 or 1.0.0-1 where the last number is the number of hot fixes made on top of the original SemVer compliant version number.
This makes it easy for anyone involved to quickly spot and trace releases.
Thnk you very much for your thorough answers, they have helped a lot. Closing this now.
@jwdonahue commented on GitHub (Oct 18, 2018):
@valecarlos
Adding a fourth digit is not semver compliant. Using prerelease tag
-1means that semver compliant tooling will ignore your patch because it sorts lower than 1.0.0. For CI build and release environments, you should be using prerelease tags for internal distribution/testing. Tracking feature sets is not possible with semver or any versioning scheme that I am aware of. That is generally achieved using feature tags embedded in release notes or databases. If you think about it, every branch will have different sets of features in it. You can't safely use repository history tags/comments for this because they can be squashed, edited or deleted.The best practice is to associate feature tags with commit hashes in a database, but that's for machines, you'll also need to track feature tags through branches for humans to understand who's working with which sets of features/bug-fixes in their branches. Anything short of a well-regulated external database, combined with check-in triggers and strong commit comments for this purpose, will not scale, and will be ineffective in the long haul. I know of some teams that generate release notes from such a database.