Only consider version tags #100
Comments
|
Good point! If you don't use tags for versions, you can skip their processing with |
|
Hi kzu Whe have the same problem. If you create a bugfix branch with gitFlow an close the branch a tag is created with the name of the bugfix branch. Like my_super_bugfix. The generated version is 0.0.0.commits.hash and not using the numbers of the latest version tag. So gitInfo should only use the tags with versions and other tags should be ignored. |
|
We have the same problem using gitlab (which generates own refs / tags) killing the versioning. :-( |
|
Hey folks, Thanks! |
Fixes #100, brings #72 in. It didn't make a lot of sense to require the entire branch or tag to be semver2, from beginning to end. It's usually the case that branches are named like `rel/vX.Y.Z`, for example, and we were forcing such common naming conventions to customize GitInfo unnecessarily. So to make it more flexible and powerful, we add two things with this commit: 1. We no longer enfore version to match from beginning of string (`^` removed from default regex). We still require the version to be the last part. However, if that still doesn't match the desired behavior, users can now override the default expression by just setting `GitBaseVersionRegex` which is now "public" and documented. 2. We also allow the filter for tags to be specified, so that "weird" tags aren't considered for matching, and can easily be filtered out by providing, for example, a `rel/v*` expression for `GitTagRegex)`.
Fixes #100, brings #72 in. It didn't make a lot of sense to require the entire branch or tag to be semver2, from beginning to end. It's usually the case that branches are named like `rel/vX.Y.Z`, for example, and we were forcing such common naming conventions to customize GitInfo unnecessarily. So to make it more flexible and powerful, we add two things with this commit: 1. We no longer enfore version to match from beginning of string (`^` removed from default regex). We still require the version to be the last part. However, if that still doesn't match the desired behavior, users can now override the default expression by just setting `GitBaseVersionRegex` which is now "public" and documented. 2. We also allow the filter for tags to be specified, so that "weird" tags aren't considered for matching, and can easily be filtered out by providing, for example, a `rel/v*` expression for `GitTagRegex)`.
Fixes #100, brings #72 in. It didn't make a lot of sense to require the entire branch or tag to be semver2, from beginning to end. It's usually the case that branches are named like `rel/vX.Y.Z`, for example, and we were forcing such common naming conventions to customize GitInfo unnecessarily. So to make it more flexible and powerful, we add two things with this commit: 1. We no longer enfore version to match from beginning of string (`^` removed from default regex). We still require the version to be the last part. However, if that still doesn't match the desired behavior, users can now override the default expression by just setting `GitBaseVersionRegex` which is now "public" and documented. 2. We also allow the filter for tags to be specified, so that "weird" tags aren't considered for matching, and can easily be filtered out by providing, for example, a `rel/v*` expression for `GitTagRegex)`. Bump to 2.1 since it might be breaking for some consumers.
I had a tag
git-info-setupthat happened to be the most recent tag in my history. Since GitInfo looks for the most recent tag, this broken the base version calculation.Since only specific patterns are allowed for base version, the git "describe" command should be filtered to those tag patterns. Otherwise, using tags for other things breaks the version. It should be valid to use tags for more than just versions.
The text was updated successfully, but these errors were encountered: