Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WeightedPreReleaseNumber null on tag #1994

Closed
tobiasdiez opened this issue Dec 16, 2019 · 9 comments · Fixed by #2222
Closed

WeightedPreReleaseNumber null on tag #1994

tobiasdiez opened this issue Dec 16, 2019 · 9 comments · Fixed by #2222
Labels
Milestone

Comments

@tobiasdiez
Copy link

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
Copy link

stale bot commented Mar 15, 2020

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.

@stale stale bot added the stale label Mar 15, 2020
@tobiasdiez
Copy link
Author

The issue is still present.

@stale stale bot removed the stale label Mar 15, 2020
@asbjornu
Copy link
Member

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

@jbaehr
Copy link
Contributor

jbaehr commented Mar 31, 2020

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
Copy link
Contributor

@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
Copy link
Contributor

jbaehr commented Apr 1, 2020

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
Copy link
Contributor

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

@asbjornu
Copy link
Member

#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
Copy link

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

Your GitReleaseManager bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants