Open Crown0815 opened 2 years ago
You may try to configure source-branches
for develop
to include release
.
@asbjornu Could you please elaborate why this should solve the issue? And why would this be necessary in case of using commit message bumping of version numbers but not in case of numbered release branches?
Because release
is not a source branch for develop
by default, and configuring it as such may force GitVersion to consider the tag on release
when calculating the version for develop
. I am not confident this is the case, but it's worth a try.
@asbjornu I adjusted my test according to your recommendation and still get the same result:
[Test]
public void MyTest()
{
var config = new Config();
config.Branches.Add("develop", new BranchConfig
{
SourceBranches = new HashSet<string>{"release"},
});
using var fixture = new EmptyRepositoryFixture();
fixture.Repository.MakeACommit();
fixture.Checkout(MainBranch);
fixture.Repository.ApplyTag("1.2.1");
fixture.BranchTo("develop");
fixture.Repository.MakeACommit("semver: feature");
fixture.BranchTo("release/some_release");
fixture.Repository.MakeCommits(1);
fixture.Repository.ApplyTag("1.3.0-beta.1");
fixture.Checkout("develop");
fixture.Repository.MakeACommit("semver: feature");
fixture.AssertFullSemver("1.4.0-alpha.1", config);
}
should be 1.4.0-alpha.1
but was 1.3.0-alpha.2
Is the configuration correct, or do I need to adjust anything else?
Seems like the 1.3.0-beta.1
tag on release/some_release
is not considered when computing the version on develop
. The "proper" way to do it is to apply tags to main
or master
. That should bump develop
as you expect.
But is this consistent with the claim made in the FAQs under Merged branch names as version source
? To be fair, it is not about merged branches, but created branches. In case of the existence of branch release/1.3.0
, the version of develop
is bumped, but if the branch were to be deleted, the version(s) on develop
would retrospectively reset. Would it not be more consistent to rely on the tags
alone, since those are (at least more) persistent?
Maybe we are just using GitVersion incorrectly, but I have the impression that there is a slight inconsistency here.
Well, the expectation is to be able to use the branch name as a version source both when it exists and its presence in the merge message once it’s been merged and deleted. But since merge messages are customisable, no guarantee can be made about the branch name as a a version source. Therefore, adding a tag on the merged commit is recommended.
This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs.
This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs.
Like you sayed the documentation says clearly to use a dedicated version numer for branches e.g. release/1.2.3. Thus this issue is not a bug.
Describe the bug
The following test
produces
with a final version on
develop
of1.4.0-alpha.1
. This is as expected and documented in the minor release branches example for gitflow.In our case, we use conventional commits and bump our version based on those. Therefore, we do not use numbered release branches, but give them random names as exemplified by the following test
However, this test fails by producing
1.3.0-alpha.2
, as shown belowExpected Behavior
I would expect the test to produce
1.4.0-alpha.1
Actual Behavior
The test produces
1.3.0-alpha.2
Possible Fix
I suspect the issue is that the versioning is based on the release branch name instead of the tag on the release branch. By changing the logic to target the tag on the release branch, the correct version might be created.
Steps to Reproduce
See above
Context
See above
Your Environment
Link to your project:Link to your CI build (if appropriate):Notes
If this is actually found to be a bug, I would be happy to provide a pull request to fix it.