I’ve added a comment to the github mailinbox issue regarding this, but my guess is that the version is not appearing as expected, because the ‘v65’ tag is a lightweight tag and not an annotated tag, and the use of git describe ... is giving us the results we’re seeing.
So, what I did instead of changing the code was to change the tag in /root/mailinabox to be annotated. You can do this with the following command (to be run as root from the /root/mailinabox directory):
date="$(git show $tag --format=%aD | head -1)"
GIT_COMMITTER_DATE="$date" git tag -a -f v65 v65
which will put you into an editor to write the annotation.
To be honest, I’m not 100% sure what will happen during the next upgrade, but I’m 90% sure it will make no difference and the upgrade won’t notice we changed a tag from lightweight to annotated, and will happily go about its business.
My reason for thinking that is because running "git status" in /root/mailinabox still shows the the working tree as being clean. If I had changed a file in the repo, on the other hand, the upgrade would complain because the working tree is not clean and refuse to continue until I reverted the change (at least that was my experience when I temporarily changed the backup.py file to deal with the duplicity issue we recently encountered).
If the next upgrade does complain about the tag being annotated, I’ll revert the tag to match upstream. I believe this can be done by deleting the tag and pulling from upstream (that works on my test setup).