WeightedPreReleaseNumber null on tag

[tobiasdiez]

We use
assembly-versioning-format: '{major}.{minor}.{WeightedPreReleaseNumber}'
in combination with
mode: ContinuousDeployment
to have an increasing build number. Everything works in a normal development workflow (PRs, direct commits etc increase the version from e.g. 1.1.1 to 1.1.2). However, as soon as we want to release a new version, we push a tag with the new version (say 2.0-beta). In this case, WeightedPreReleaseNumber is null (or empty) for some reason which leads to the invalid build number 2.0. (notice the missing last bit of the version). I would have expected this to be 2.0.0 (or more generally: 2.0.x where x is the weight corresponding to the beta tag).

Full GitVersion file:
https://github.com/JabRef/jabref/blob/master/GitVersion.yml/GitVersion.yml

[stale]

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. Thank you for your contributions.

[tobiasdiez]

The issue is still present.

[asbjornu]

Are you able to reproduce this problem in a RepositoryFixture and submit a PR with it?

[jbaehr]

We're hit by the same issue. In order to have strictly increasing AssemlyFileVersion (the unmanaged one) to satisfy Windows Installer's need we used to apply the weight on our own and inject it via an environment variable (cf. #1385). In order to get rid of this external custom logic we want to switch to the "WeightedPreReleaseNumber" (cf. #1433). It works great up to the point where you build from a tag.

Right now one can only configure a pre-release-weight per branch; I think we need a similar way for tags (i.e. a regex for matching tags, then configure how to version them. Just like the branch config works)

@ruhullahshah, any thoughts on that?

[ruhullahshah]

@jbaehr From the problem description, it seems like the TaggedCommitVersionStrategy wins during the version calculation and since there are no weights attached to tags as you described already, we get the observed behavior. What you suggest sounds like a plausible solution to me.

I would also like to bring to your notice a related, although not exactly the same issue that might affect a potential PR for the issue we are discussing here.

[jbaehr]

That the TaggedCommitVersionStrategy wins is expected and totally fine. We just need a way to set the weight for this case.

For our scenario it would be sufficient to apply a static weight for tags in general; we only tag final versions.
The proposal with the "(git-)tag configuration", analog to the existing branch configuration, was motivated by @tobiasdiez example above, where he seems to need git tags for pre-releases. From the issue that @ruhullahshah mentioned (I did not follow it in all details), it appears that others need that, too.

Regarding a potential PR: I could imagine, that designing a fully configurable solution requires a more extensive use-case collection first. A static weight, applicable for all git-tags could be a first step. This static weight can later serve as a default, in case no specific rule matches the current git tag. So I don't see this first step as a potential blocker for more sophisticated solutions later. And it offers already a benefit on its own, namely for us who only tag final versions.

[ruhullahshah]

@jbaehr I agree. In case no one has volunteered so far, I can pick this up.

[asbjornu]

#2222 was just merged and should fix this, so closing. Please reopen after the next release if it there are still issues to be solved.

[github-actions]

🎉 This issue has been resolved in version 5.3.3 🎉
The release is available on:

• GitHub Release
• Chocolatey Package
• .Net Global Tool

Your GitReleaseManager bot 📦🚀