[Build] Locked Version Tag Reference #3200
Conversation
To get a unique version for every commit on Master, git describe is used. This produces a unique (monotonically increasing) string by getting the number of commits since a tag. We originally let git decide which tag to use, which I assumed was the most recent tag; however, some users have been noticing that the version has been relative to different tags (like v9.0.0-candidate). In the future, we may want to also control when we want to move the tag this version is relative to manually, instead of letting Git decide. To make this more robust and controllable, forced the git describe to be relative to a specific tag which is set in VTR's CMake (similar to the major version number).
github-actions
bot
added
build
|
Thanks for the PR Alex! I think this fix has one big issue. Here's what users would see with this change: As you can see the revision field only contains the commit hash and nothing else. Before this change there were more information there such as the latest reachable tag name and the number of commits since that tag. Another way to fix the problem with a wrong revision name without forcing 'git describe' and hard coding the revision number (and just giving up on having a revision name when the hard coded name is not found) could be adding a new "v9.0.0-master" or "v9.0.0-dev" tag to the commit in which v9 started branching off master. 'git describe' is returning the most recent reachable tag, it's just that the v9 tag is not reachable from master and we can't really change the git history now. I think it's worth having a discussion about this vs your approach. To sum this up, the revision name that's printed by VPR is given by the 'git describe' command. Git describe moves backwards in the branch you're currently in until it hits a tag and uses that as part of the revision name, plus a bunch of other things. The current problem is that the v9 tag points to a commit that's not in master so 'git describe' does not see it and instead sees the v9-candidate or even the v8 tag. Another thing here is that the v8 tag is annotated while the v9-candidate tag is not and is a lightweight tag. 'git describe' by default only considers annotated tags but the --tags option also considers lightweight tags. I think this is why VPR used to print out v8 while the v9-candidate tag was reachable before your previous changes. The reason, I believe, is that we cherry-picked some hot-fixes from master to v9 branch, but instead of making a new v9.0.1 tag or something similar the v9.0.0 tag was moved to the new commit. I also think we should add some documentation for VtR release procedures to avoid doing this for future releases. Also the current v9 tag is not pointing to the latest v9 commit with all the fixes so we probably should add a v9.0.1 tag there too. Please correct me if any of the above is wrong! |
To get a unique version for every commit on Master, git describe is used. This produces a unique (monotonically increasing) string by getting the number of commits since a tag.
We originally let git decide which tag to use, which I assumed was the most recent tag; however, some users have been noticing that the version has been relative to different tags (like v9.0.0-candidate). In the future, we may want to also control when we want to move the tag this version is relative to manually, instead of letting Git decide.
To make this more robust and controllable, forced the git describe to be relative to a specific tag which is set in VTR's CMake (similar to the major version number).