VERSION CONFUSION

I've been under the impression that UNM Gopher's upstream 
development was long abandoned and, like in so many such cases, 
Debian was maintaining their own updated fork with minor tweaks so 
they can keep building packages for it. This seemed clear to me 
since when I first downloaded the source code to build the latest 
official version (I don't usually try the Debian forks unless I 
have trouble compiling, in case their fixes cause issues in 
different build environments), the Gopher directory claiming to be 
"THE MASTER SITE" for new UMN Gopher development only showed 
downloads for versions up to v3.0.11.

UMN Gopher 3.0.11 was released in 2005, and I was doing this 
sometime a little before I started this phlog, so about 2019 or 
2018, so it looked like "new" development was long dead. But 
recently I checked again and now there's a gopher_3.0.17.tar.gz 
file there, still absent any releases in-between:

gopher://gopher.quux.org/1/devel/gopher/Downloads

Further investigation shows that the maintainer of the Debian 
package is the same person (their matching name/email is actually 
in the Gopher+ info there, although of course you need UMN Gopher 
to read that unadopted protocol extension), they've just not been 
bothering to update their own master download site. I guess the 
fact that the downloads gophermap starts with this text should have 
been a hint that it wasn't really a trustworthy source of sources:

"The latest source download is: gopher-3.0.2.tar.gz"

But still I wonder, how come in current Debian/Devuan I don't 
remember seeing such a high Gopher version as v3.0.17 when viewing 
the '?' help page (the only place where I know UMN Gopher to report 
its own version number)? It turns out the UMN Gopher in the Debian 
11 (bullseye) "gopher" package reports its version there as 
v3.0.12, yet the package version is 3.0.17.3, and the changelog 
shows the very latest Debian package version is 3.0.17.4 from just 
last month!

https://metadata.ftp-master.debian.org/changelogs//main/g/gopher/gopher_3.0.17.4_changelog

So depending on where you look, at the moment the current UMN 
Gopher version is:

Text on the top of the master UMN Gopher download site:
v3.0.2

Files downloadable from the master UMN Gopher download site:
v3.0.17

Debian (testing) Changelog:
v3.0.17.4

UMN Gopher itself, installed from the Debian (oldstable) 
gopher_3.0.17.3 package:
v3.0.12

But it doesn't mean there are different forks, as was my earlier 
assumption, the author just doesn't seem very focused on updating 
version info. The 3.0.17.* changes look specific to the Debian 
package anyway, so that's reasonable (or nothing more than the 
usual confusion brought by Debian-specific sub-versions). The other 
mis-matches probably should be fixed, but since last time I emailed 
a Gopherhole author to suggest they fix a minor issue they called 
me an asshole for wasting their time, I think I'll leave it and 
presume it'd be fixed already if they actually cared.

VERSION TRACKING SOLUTIONS?

I couldn't help musing about how best to track down current source 
code releases for small software projects in general. Debian 
packages serve as a useful mirror/database of upstream source 
versions, and was the best source of info in this case, yet with 
Dillo they've reportedly refused to switch to the new maintainer's 
releases (3.1 and later), so only offer patched v3.0.5 which won't 
load many HTTPS websites because it lacks SNI support. This is 
presumably because the development site moved to 
https://dillo-browser.github.io after the old dillo.org site was 
domain-poached, similar to another package I used which was 
discontinued by its Debian package maintainer claiming "dead 
upstream" when the project's development site moved (in spite of an 
announcement at the old one!).

There may be good reasons for Debian package maintainers being 
difficult like this, in the name of security, but it means they're 
not a solution to my problem. I suppose the only thing that might 
work is if the software license of source code required that every 
new version or fork register into some distributed software version 
database. A compulsory release message in a detailed standardised 
format posted to a specific Usenet newsgroup would be a simple 
solution using existing distributed infrastructure, also quite 
automate-able.

If that had been put into popular software licenses like the GPL in 
the 1990s (albeit unfairly to those software developers without 
convenient internet access), it might have worked to tidy the mess 
of dead development sites and competing forks that confuses me (and 
probably many others) today. These days it's probably too late 
because so much established open-source software uses existing 
licenses which lack such a requirement, and new unmoderated 
distributed message systems are more niche than Usenet was back 
then. So it wouldn't be adopted widely enough today to be generally 
useful.

Also of course that still wouldn't stop programs like UMN Gopher 
mis-reporting their own version number in help info. That's just 
one of the quirks which hobby software seems to inevitably 
accumulate with age.

 - The Free Thinker