Jack posted on Wed, 24 Sep 2025 13:15:34 -0400 as excerpted:

> I am running pan compiled from git head, but it still identifies itself
> as 0.164.  This is both in the Help/About Pan popup and command line
> "pan -v".
> 
> Might I have mis-configured something, or is there any point in opening
> an issue for this?

So as the current date vs quoted message date suggests, I've been busy and 
haven't looked at this list/group for awhile.  This is my first reply 
after loading it...

... And I've not rebuilt pan in a bit either, but I did just do a git pull 
(without a full build), and there's only a couple commits since ORIG_HEAD 
and they don't pertain to the version, so should be similar.

As you can probably see from my headers, I'm listing (in about, and 
presumably the same in the user-agent header) 0.164 as well.

In general (said as someone who runs over 100 packages including most of 
my kde installation live-git...), what projects report for live-git 
versions can vary, depending on individual project policy.  Some bump 
version post-release so live is the next to-come version; some do it pre-
release along with CHANGES updates or the like so live is the latest 
released version; others do the equivalent of a git status call and report 
last release plus N commits and the current commit hash, if that succeeds, 
falling back to set version if not (relying on a tarball git status call 
to fail).

IIRC pan /used/ to do the tag+N+H thing back when it used autotools, but 
it seems that didn't carry forward to cmake, which just uses its set 
release variables, which are apparently now updated pre-release so live 
reports as the old release.  There's probably a cmake recipe to report git 
status output versions in live builds, but pan's evidently not using it.

With my pan group/list regular hat on, not having the git commit hash in 
user-agent headers is a bit inconvenient, but OTOH, if I were an active 
binary or controversial text group poster and was taking steps to reduce 
traceability, even the version number in user-agent is a bad enough 
pseudonymity/privacy-break and I'd not want commit-hash.

OTOH, I suppose folks advanced enough to be doing live-git builds can in 
most cases edit what pan's reporting, should they want to...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


_______________________________________________
Pan-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/pan-users

Reply via email to