fix(core): use existing patch tags as patch-counter anchor on release…#87
Open
denis-markushin wants to merge 1 commit into
Open
fix(core): use existing patch tags as patch-counter anchor on release…#87denis-markushin wants to merge 1 commit into
denis-markushin wants to merge 1 commit into
Conversation
… branches Previously `calcVersionInRelease` derived the patch number purely from the commit distance between the release branch and the default main branch. That approach breaks the moment a release branch is merged back into main: the merge brings every release-branch commit into main's history, shifting the merge-base forward and silently lowering the computed patch number to a value that has already been released. The next `makeRelease` / publish attempt then tries to re-create an existing tag and fails. This change uses `v<major>.<minor>.<patch>` tags reachable from HEAD as the authoritative anchor when they exist: the patch number becomes `latest_tag_patch + commits_since_that_tag`. Both annotated and lightweight tags are honoured; tags that do not sit on the release branch's history are ignored. When no matching tags exist yet the calculation falls back to the original distance-from-main behaviour, so existing projects that have never tagged a patch release see no change.
orchestr7
reviewed
May 17, 2026
| "${releases.releaseBranches}" | ||
| ) | ||
|
|
||
| // Prefer existing patch tags when present: they are an authoritative record of what has |
Owner
There was a problem hiding this comment.
Unfortunately I do not like the way of making any calculation based on tags. There are a lot of tools who do this already. We need to think wisely if we really want to be a yet another tool which depends on tags.
Owner
There was a problem hiding this comment.
We had a lot of problems with those tools. A lot of CI/release systems add their tags (for example GitHub) and that affects the work of those instruments :(
That's why I have chosen release/* branches and the distance from main/master branch
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
… branches
Previously
calcVersionInReleasederived the patch number purely from the commit distance between the release branch and the default main branch. That approach breaks the moment a release branch is merged back into main: the merge brings every release-branch commit into main's history, shifting the merge-base forward and silently lowering the computed patch number to a value that has already been released. The nextmakeRelease/ publish attempt then tries to re-create an existing tag and fails.This change uses
v<major>.<minor>.<patch>tags reachable from HEAD as the authoritative anchor when they exist: the patch number becomeslatest_tag_patch + commits_since_that_tag. Both annotated and lightweight tags are honoured; tags that do not sit on the release branch's history are ignored. When no matching tags exist yet the calculation falls back to the original distance-from-main behaviour, so existing projects that have never tagged a patch release see no change.Closes: #86