-
Notifications
You must be signed in to change notification settings - Fork 652
[Feature] provide an option to choose which version type use to update Build.BuildNumber #2580
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
Comments
This is a great suggestion, but I think, unfortunately, it points to the need for GitVersion to do less. Having to change GitVersion in order to have the AzDO Task change its behavior indicates that we have drawn the wrong boundaries around the different moving parts of our code and that the architecture needs to change. Ideally, GitVersion should only produce version variables and then an AzDO Task or any other implementation of GitVersion can take these version variables and do whatever it pleases with them without having to change anything within GitVersion itself. #2262 and #2275 deals with this refactoring. Introducing a configuration property in |
I agree that would be a great addition, but in version 6 . There we have a clear separation of the version calculation and output, Maybe we add it to 6.0.0 milestone |
Workaround:
|
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 was closed because it has been stalled for 30 days with no activity. Thank you for your contributions |
I'm not entirely sure how it works, but when called from azure devops it updates pipeline version to current "FullSemVer"
I suspect it has to do with /output buildsystem and generated yml file, that is somehow gets propagated into Build.BuildNumber variable later on.
Currently there is no way of deciding on format of version and it would be great to be able i.e. to use SemVer rather then FullSemVer
Initially created at GitTools/actions#318 but it seems its handled by gitversion itself
The text was updated successfully, but these errors were encountered: