GitVersion
GitVersion copied to clipboard
[Docs] releasing alpha's/beta's/rcs/releases from the same branch
I've been reading and rereading the docs, to be honest I'm even finding it hard to understand exactly how you're supposed to use gitversion, and perhaps why... it's very unclear to be how to do, for example a git version release of 2.5.0-alpha.10 when I already have a tag v2.5.0-alpha.9 where in a future release I'll just want to ship v2.5.0 all from the same branch.
Realistically I feel like the documentation needs some serious tutorials.
If you use GitVersion where you tag it yourself, then what's the benefit of GitVersion?
I realize this may seem like a question, and it is but the answers should be in the documentation, and in reading it, I can't figure it out.
Also Im finding it a bit weird that without next-version, when looking at these tags it wanted to increment 2.2
Realistically I feel like the documentation needs some serious tutorials.
Sure, we happily accept pull requests!
If you use GitVersion where you tag it yourself, then what's the benefit of GitVersion?
GitVersion generates predictable, repeatable version numbers for the same Git commit in the same branch of the same repository across all computers that have the same commit, branch and repository checked out. The only thing you need to do is to tell GitVersion the version number of your latest (public) release. You do this by adding a git tag.
I realize this may seem like a question, and it is but the answers should be in the documentation, and in reading it, I can't figure it out.
I agree that the documentation can be improved. If you have concrete suggestions to how, we would be ecstatic to receive pull requests that improves it!
Also Im finding it a bit weird that without next-version, when looking at these tags it wanted to increment 2.2
I need more information about the Git history and configuration of this repository to be able to answer that.
If you use GitVersion where you tag it yourself, then what's the benefit of GitVersion?
I think this is actually a good question. Why it is not possible to define a workflow where the semantic version will be determined per branch convention without any tags? For sure you need for that workflow a dedicate merge message which includes the released version number. At this moment we are detecting the correct number already on the main branch using the MergeMessageVersionStrategy class.
I think this could be a feature maybe in the future.
I suspect that not having any tags will cause the version calculation to become very slow over time because GitVersion would have to iterate over every commit from HEAD back to the initial commit in the repository on every run. I'm not opposed to GitVersion supporting it, but I'm afraid it's going to be so slow it becomes unusable for large repositories.
I suspect that not having any tags will cause the version calculation to become very slow over time because GitVersion would have to iterate over every commit from
HEADback to the initial commit in the repository on every run. I'm not opposed to GitVersion supporting it, but I'm afraid it's going to be so slow it becomes unusable for large repositories.
Good point. Of course for that the performance needs to be tested.
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