improvements to the inference of the version from the tag #616
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The current implementation of cpm_get_version_from_git_tag() has some odd behavior in scenarios that do not perfectly match the expected v#.#.# format. This change attempts to better clarify and slightly expand the functionality. The motivating event for this change was when I attempted to bring in avro, which uses a tag format that looks like this: "release-1.12.0". The current implementation was not properly parsing out the 1.12.0 version.
This change creates two scenarios. In the first, we check for the appearance of "v" followed by a number anywhere in the tag. If that is encountered, then we treat that number and any number or dot following it as the version number. This could be made more restrictive by requiring that a dot also appear, though this limitation does not exist in the current version and could break current situations. This case is meant to mimic the current approach.
The second case is less restrictive and simply looks for numbers followed by a dot and more numbers anywhere in the string. This will handle any case where the version number appears mid string. I think the current regex was meant to handle this scenario, but it was not actually working correctly.
Let me know what your thoughts are. I'm happy to walk through some of the issues I was encountering as I diagnosed the problem.