Replies: 1 comment 2 replies
-
Surely not, since that commit is tag v4.1.3. I think you mean 4deb6e5
The develop branch is currently one commit ahead of master, which is one commit ahead of v4.1.4 You're probably right that for consistency v4.1.4 would point to 4deb6e5. However in practice it doesn't make any difference since the content is the same:
It's rather hard to change it now, since slipping the tag in the main repository doesn't slip the tag for anyone who has already picked it up. See: https://git-scm.com/docs/git-tag#_on_re_tagging |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Deployment Type
Self-hosted
Triage priority
N/A
NetBox Version
v4.1.3
Python Version
3.12
Steps to Reproduce
I have a GitHub workflow in my repo to track NetBox master branch everyday. It checks the tags and find out the latest release by parsing the latest tag. Then I do code review again and merged to my local main branch.
It works well for previous releases. It stopped working with v4.1.4.
The tag for latest version v4.1.4 doesn't point the commit of "Merge pull request" in master branch. Or the latest commit in master branch is not in the repo tag list. There is inconsistence.
With
git ls-remote --tags
orgit ls-remote --tags https://github.com/netbox-community/netbox.git
the tags can be feteched.The tag v4.1.4 points to d2cbdfe in develop branch
While other tags pointed to "Merge pull request" in master branch.
Tag v4.1.4 should point to 6ea0c0c in master branch
Expected Behavior
Tag v4.1.4 should point to 6ea0c0c in master branch
Observed Behavior
Tag v4.1.4 points to d2cbdfe in develop branch
Beta Was this translation helpful? Give feedback.
All reactions