ashoke
January 15, 2024, 7:03pm
1
Hello, I just did a Pi-hole -up on my v6 instance plus server reboot but when I query the /info/version API it still shows the previous version.
{
"version": {
"core": {
"local": {
"version": "v5.17.1-265-gebb0db0a",
"branch": "development-v6",
"hash": "ebb0db0a"
},
"remote": {
"version": "v5.17.3",
"hash": "ebb0db0a"
}
},
"web": {
"local": {
"version": "v5.19-641-g9f04f7ab",
"branch": "development-v6",
"hash": "9f04f7ab"
},
"remote": {
"version": "v5.21",
"hash": "9f04f7ab"
}
},
"ftl": {
"local": {
"hash": "806d6086",
"branch": "development-v6",
"version": "vDev-806d608",
"date": "2024-01-13 20:44:39 +0100"
},
"remote": {
"version": "v5.24",
"hash": "806d6086"
}
},
"docker": {
"local": null,
"remote": null
}
},
"took": 0.00015687942504882812
}
ashoke
January 15, 2024, 7:05pm
2
Desktop shows that it is updated.
Have a look at the hashes. They are the same for local and remote, you are using the latest versions.
ashoke
January 15, 2024, 7:31pm
5
Thank you, but shouldn't the local:version also be updated to reflect that ?
DL6ER
January 15, 2024, 7:48pm
7
There is an inconsistency about how the remote version is sourced:
As you can see, we are getting the remove version by looking the tag of the last release - completely neglecting any possible deviating local branch.
This will never match the local version for branch != master
.
I don't think there is a similar "descriptive version" we could source from Github so maybe we should set local
/remote
versions to null
if branch != master
to emphasize the comparison needing to be done on a hash-basis.
DL6ER
January 15, 2024, 8:01pm
9
development-v6
← dix/remote_version
opened 08:00PM - 15 Jan 24 UTC
# What does this implement/fix?
Do not store remote version in versions file … if on custom branch. It's always wrong here
---
**Related issue or feature (if applicable):** N/A
**Pull request in [docs](https://github.com/pi-hole/docs) with documentation (if applicable):** N/A
---
**By submitting this pull request, I confirm the following:**
1. I have read and understood the [contributors guide](https://docs.pi-hole.net/guides/github/contributing/), as well as this entire template. I understand which branch to base my commits and Pull Requests against.
2. I have commented my proposed changes within the code.
3. I am willing to help maintain this change if there are issues with it later.
4. It is compatible with the [EUPL 1.2 license](https://opensource.org/licenses/EUPL-1.1)
5. I have squashed any insignificant commits. ([`git rebase`](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html))
## Checklist:
- [x] The code change is tested and works locally.
- [x] I based my code and PRs against the repositories `developmental` branch.
- [x] I [signed off](https://docs.pi-hole.net/guides/github/how-to-signoff/) all commits. Pi-hole enforces the [DCO](https://docs.pi-hole.net/guides/github/dco/) for all contributions
- [x] I [signed](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) all my commits. Pi-hole requires signatures to verify authorship
- [x] I have read the above and my PR is ready for review.
development-v6
← fix/remote_version
opened 08:01PM - 15 Jan 24 UTC
# What does this implement/fix?
See title, needs https://github.com/pi-hole… /pi-hole/pull/5549
---
**Related issue or feature (if applicable):** N/A
**Pull request in [docs](https://github.com/pi-hole/docs) with documentation (if applicable):** N/A
---
**By submitting this pull request, I confirm the following:**
1. I have read and understood the [contributors guide](https://docs.pi-hole.net/guides/github/contributing/), as well as this entire template. I understand which branch to base my commits and Pull Requests against.
2. I have commented my proposed changes within the code.
3. I am willing to help maintain this change if there are issues with it later.
4. It is compatible with the [EUPL 1.2 license](https://opensource.org/licenses/EUPL-1.1)
5. I have squashed any insignificant commits. ([`git rebase`](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html))
## Checklist:
- [x] The code change is tested and works locally.
- [x] I based my code and PRs against the repositories `developmental` branch.
- [x] I [signed off](https://docs.pi-hole.net/guides/github/how-to-signoff/) all commits. Pi-hole enforces the [DCO](https://docs.pi-hole.net/guides/github/dco/) for all contributions
- [x] I [signed](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) all my commits. Pi-hole requires signatures to verify authorship
- [x] I have read the above and my PR is ready for review.
The remaining bit for discussion is if we should set .local.version
to null
as well in this context (even when it is correct, it may not be very helpful)
1 Like
I think it's fine to keep it for now. It gives at least some indication at which point the custom branch diverged.
Add:
And having a lot of null
in the version information makes the impression something might be wrong.
1 Like