[GH-ISSUE #370] Handling new medium/major version #2010

New Issue

GiteaMirror · 2026-04-20T09:53:05-05:00

GiteaMirror commented

2026-04-20 09:53:05 -05:00

Originally created by @david-rouchet on GitHub (May 8, 2017).
Original GitHub issue: https://github.com/semver/semver/issues/370

How do people generally deal with incrementing the next expected version without conflicting with potential intermediate releases:

For instance, the version 1.0.2 is the last released. It is planned to create a new version with some features, for instance we expect 1.1.0 being the next medium version (on branch A). If the versioning during the dev is 1.1.0-beta.3 (on branch A) for instance and meanwhile another branch (branch B) from 1.0.2 has been created to fix some bugs but ends up in a small feature change that lead to naming this intermediate version 1.1.0, then the previous 1.1.0-beta.3 (branch A) has no meaning anymore, because a version called 1.1.0 has been released from branch B.

Any advise?

Originally created by @david-rouchet on GitHub (May 8, 2017). Original GitHub issue: https://github.com/semver/semver/issues/370 How do people generally deal with incrementing the next expected version without conflicting with potential intermediate releases: For instance, the version 1.0.2 is the last released. It is planned to create a new version with some features, for instance we expect 1.1.0 being the next medium version (on branch A). If the versioning during the dev is 1.1.0-beta.3 (on branch A) for instance and meanwhile another branch (branch B) from 1.0.2 has been created to fix some bugs but ends up in a small feature change that lead to naming this intermediate version 1.1.0, then the previous 1.1.0-beta.3 (branch A) has no meaning anymore, because a version called 1.1.0 has been released from branch B. Any advise?

GiteaMirror closed this issue

2026-04-20 09:53:06 -05:00

GiteaMirror commented

2026-04-20 09:53:06 -05:00

@arcticicestudio commented on GitHub (May 9, 2017):

Why don't you merge branch B into branch A or the other way around? If both branches include features changes they are correctly mapped to version 1.1.0. If this doesn't fit you can merge branch B into branch A and release branch B as version 1.1.0 and branch A as version 1.2.0.

@arcticicestudio commented on GitHub (May 9, 2017): Why don't you merge branch *B* into branch *A* or the other way around? If both branches include features changes they are correctly mapped to version 1.1.0. If this doesn't fit you can merge branch *B* into branch *A* and release branch *B* as version 1.1.0 and branch *A* as version 1.2.0.

GiteaMirror commented

2026-04-20 09:53:07 -05:00

@david-rouchet commented on GitHub (May 9, 2017):

In that particular scenario, the work on branch B is completed way before the one on branch A, hence the desire is to release what is in branch A (with a new meanful version 1.1.0) while the branch B is still under developement. Is that make sense?

@david-rouchet commented on GitHub (May 9, 2017): In that particular scenario, the work on branch B is completed way before the one on branch A, hence the desire is to release what is in branch A (with a new meanful version 1.1.0) while the branch B is still under developement. Is that make sense?

GiteaMirror commented

2026-04-20 09:53:08 -05:00

@jwdonahue commented on GitHub (Nov 28, 2017):

Your dev-ops problem is beyond the scope of SemVer, but I can say that I have solved this in the past by requiring non-master branches to build/release packages with the repo/branch-name embedded in the package names. Each branch has it's own version history that begins with a fork from some branch, and that data (including commit hash) is encoded in the build metadata part of ALL version strings used in
or appended to build artifacts. Artifact provenance is then propagated via the SemVer strings in the packages produced by that branch. When you merge back to a parent/master branch, you include the latest SemVer string(s) and commit hash from the child branch in the merge commit message.

It's a kludge, and is probably lossy wrt to full provenance of every artifact from the perspective of the parent/master branch, but if you archive the child branches, that provenance can be recovered with some manual spelunking.

Since this problem is outside the scope of SemVer, please close this issue at your earliest convenience.

@jwdonahue commented on GitHub (Nov 28, 2017): Your dev-ops problem is beyond the scope of SemVer, but I can say that I have solved this in the past by requiring non-master branches to build/release packages with the repo/branch-name embedded in the package names. Each branch has it's own version history that begins with a fork from some branch, and that data (including commit hash) is encoded in the build metadata part of ALL version strings used in or appended to build artifacts. Artifact provenance is then propagated via the SemVer strings in the packages produced by that branch. When you merge back to a parent/master branch, you include the latest SemVer string(s) and commit hash from the child branch in the merge commit message. It's a kludge, and is probably lossy wrt to full provenance of every artifact from the perspective of the parent/master branch, but if you archive the child branches, that provenance can be recovered with some manual spelunking. Since this problem is outside the scope of SemVer, please close this issue at your earliest convenience.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#2010