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

You are viewing proxied material from aussies.space. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.