mirror of
https://github.com/semver/semver.git
synced 2026-07-10 19:50:47 -05:00
[GH-ISSUE #390] Versioning for QA/Production #6282
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#6282
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 @writemevenkat on GitHub (Aug 29, 2017).
Original GitHub issue: https://github.com/semver/semver/issues/390
Let's say I deployed initial version 1.0.0 in production and later got an enhancement which I begin it as 1.1.0-SNAPSHOT. Once the development is complete, moved version to QA by removing snapshot as (1.1.0). Now QA team reports a bug in my current version and to fix it I have to build another version with 1.1.1 and move the same to QA. The question is, Now I have 2 versions in release repository with one invalid version. How to handle/avoid this situation ?
@klehelley commented on GitHub (Aug 30, 2017):
Personally I would consider code that is not yet ready for production (since it has yet to pass QA) as a pre-release version. In that case, you can apply rule 9 of SemVer, and append a specific identifier to the version (for example in your case
1.1.0-qa.1or1.1.0-rc.1).Do note that this version number identifies a given version of the code, and that several version numbers can identify one version of the code. So if version
1.1.0-rc.1passes QA and is deemed ready for production, it can be "promoted" to1.1.0(that is, both1.1.0-rc.1and1.1.0identify the same version of the code), a version that can then be used in production. Otherwise you can later release version1.1.0-rc.2, and as long as QA has not validated anything version number1.1.0stays available.If you are not comfortable with this way of working, or that the tools you have make it hard to apply that strategy in a safe manner, I do not think it would be too bad a thing to actually use release version numbers, as you present in your question.
In that case, you have to properly document which versions are "production-ready" and which ones are not. But the end-users may be confused to have to migrate from
1.0.5to1.1.3, with no other public version being released in-between (that point is moot if your end-users do not really have to bother with the release version number, but if that is the case your situation might actually be out of the scope of SemVer).@sgryphon commented on GitHub (Sep 7, 2017):
"migrate from 1.0.5 to 1.1.3" would not be compliant with SemVer 2.0. When the minor version number increments the patch MUST reset to 0, so release 1.0.5 can be followed by 1.0.6, 1.0.253, 1.1.0, 1.8.0, or 392.0.0, but can't be followed by 1.1.3
@klehelley commented on GitHub (Sep 7, 2017):
Jumping straight from
1.0.5to1.1.3wouldn't, but in my example, releases1.1.0,1.1.1and1.1.2actually exist (I should have made that clear, my fault). However, they are not made public because they have failed QA.So in that sense, SemVer would still be followed. But yes, that way of working would be less than ideal.
Unless there are serious obstacles preventing to use them, in @writemevenkat 's case pre-release version numbers should be preferred.
@silkentrance commented on GitHub (Nov 22, 2017):
@klehelley @writemevenkat
Why not still release a 1.1.0 even though it initially failed QA?
What hinders you from releasing a 1.1.0 after that it succeeded QA?
After all, it is just a branch in the repository that is put under test.
And while the branch does not succeed during test, it is still a candidate for release.
Just put more effort into fixing the issues in that branch and off you go.
What is so difficult about such simple things?
@jwdonahue commented on GitHub (Oct 11, 2018):
@sgryphon, where in the spec that it say that though shalt not release 1.0.5 followed by 1.1.3? While the spec says reset lower fields on a version bump, it does not say you must publish every version or that they should be released in any particular order.
@jwdonahue commented on GitHub (Oct 11, 2018):
@writemevenkat, I believe your question has been answered. Unless you require further clarification or intend to issue a PR to resolve this issue, please close it at your earliest possible convenience.