"appname" in version shouldn't change keys of "tahoe --version"

[warner]

When Zandr was merging the recent 1.3.0 release into his "tahoe-server" branch, he had to do a global-search-and-replace of "allmydata-tahoe" with "tahoe-server". Unfortunately it looks like this also affects the output of "tahoe --version" in a negative way: the "key" (i.e. the thing on the left side of the colon) changes. The relevant part of the output goes from:

allmydata-tahoe: 1.3.0-r5678

to:

tahoe-server: 1.3.0-r1234

Likewise, the version dictionary that flogtool tail retrieves sees a new key name. I seem to recall that there were some other places which were affected that I'd prefer were not, but I don't remember which ones right now.

This makes it difficult for external processes to correctly query Tahoe for its version string. I think that "tahoe --version" and the version data given to foolscap should use a fixed key (perhaps "tahoe"), and have a value which contains the combined appname and release number: tahoe: allmydata-tahoe-r5678 or tahoe: tahoe-server-r5678.

[zooko]

Per 14d23d99a5d8f15a, it should be spelled tahoe-server/r5678, and should be implemented by using src/allmydata/__init__.py@20090213043738-92b7f-c3ed621c433462b56d47f01bbaf0c17ad2d78365's __full_version__ attribute.

It seems slightly weird for the key to be tahoe when the app name might not include "tahoe" at all... Maybe tahoeapp?

[warner]

hm, seems like "tahoeapp" is weird for a key that specifically excludes the application's name :). I think a key of "tahoe" would be appropriate, if we think of that as the name of the protocol and not necessarily the name of the application. Or maybe as the name of the codebase's ancestry as opposed to later downstream customizations.

On the other hand, maybe we shouldn't expect that a renamed variant is closely related to the original.. maybe the key *should* change. I dunno.

[zooko]

For what it is worth I think of LAFS as the protocol/specification and tahoe as the project and the first working implementation.

[davidsarah]

The server implementation version is not the same thing as the protocol version. They should probably be separate keys (e.g. server-version: __full_version__ and lafs-version: ...). It is OK if the lafs-version matches the Tahoe version number while there is only one implementation.

[zooko]

Let's see where are the docs of our versioning scheme...

Here:

​http://tahoe-lafs.org/trac/tahoe-lafs/wiki/Versioning

So the current protocol version is "v1" and I guess it will remain "v1" until we switch to an entirely new protocol layered on top of HTTP instead of on top of TCP+SSL+Foolscap (#510). The current storage servers return a version dict like this to describe themselves:

{ "http://allmydata.org/tahoe/protocols/storage/v1" :
	                    { "maximum-immutable-share-size": remaining_space,
	                      "tolerates-immutable-read-overrun": True,
	                      "delete-mutable-shares-with-zero-length-writev": True,
	                      },
	                    "application-version": "allmydata-tahoe/1.6.1-r4264",
	                    }

(See src/allmydata/storage/server.py@4164#L267.)

[davidsarah]

Ah, so this doesn't affect the on-the-wire protocols, only how the CLI reports its version. That doesn't seem very important to me, since the output of tahoe --version clearly is about implementation dependencies, and anything that was parsing it could easily handle any changes in the keys if it needed to. Why did "allmydata-tahoe" need to be replaced with "tahoe-server" in Zandr's branch, anyway?

[zooko]

But about this actual ticket, I currently think that "appname" in version should change keys of tahoe --version. tahoe --version emits a set of Python packages, like this:

$ ./bin/tahoe --version
allmydata-tahoe: 1.6.1-r4264, foolscap: 0.4.2-zsetupztime, pycryptopp: 0.5.15, zfec: 1.4.5, Twisted: 8.2.0, Nevow: 0.9.18, zope.interface: 3.1.0c1, python: 2.5.4, platform: Darwin-8.11.1-i386-32bit, sqlite: 3.1.3, simplejson: 2.0.9, argparse: 0.8.0, pyOpenSSL: 0.9, pyutil: 1.6.0-4, zbase32: 1.1.0, setuptools: 0.6c12dev, pysqlite: 2.3.2

The "allmydata-tahoe" part of that is the name of a software package, and if you make a different software package which implements the LAFS protocol and/or which reuses some of the Tahoe source code then you should use a different name in that slot.

If you agree, let's close this ticket as wontfix.

[davidsarah]

Replying to zooko:

The "allmydata-tahoe" part of that is the name of a software package, and if you make a different software package which implements the LAFS protocol and/or which reuses some of the Tahoe source code then you should use a different name in that slot.

If you agree, let's close this ticket as wontfix.

I agree (except for nitpicking about the meaning of wontfix vs invalid :-)