Opened at 2009-03-04T22:38:17Z
Closed at 2010-03-25T05:14:30Z
#652 closed defect (invalid)
"appname" in version shouldn't change keys of "tahoe --version"
Reported by: | warner | Owned by: | somebody |
---|---|---|---|
Priority: | minor | Milestone: | undecided |
Component: | packaging | Version: | 1.3.0 |
Keywords: | version forward-compatibility | Cc: | |
Launchpad Bug: |
Description
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.
Change History (8)
comment:1 Changed at 2009-03-04T23:21:40Z by zooko
comment:2 Changed at 2009-03-09T00:25:05Z by 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.
comment:3 Changed at 2009-03-09T00:42:41Z by zooko
For what it is worth I think of LAFS as the protocol/specification and tahoe as the project and the first working implementation.
comment:4 Changed at 2010-03-25T02:33:46Z by davidsarah
- Keywords version forward-compatibility added
- Milestone changed from undecided to 1.7.0
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.
comment:5 Changed at 2010-03-25T04:37:34Z by 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", }
comment:6 Changed at 2010-03-25T04:49:23Z by davidsarah
- Milestone changed from 1.7.0 to undecided
- Priority changed from major to minor
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?
comment:7 follow-up: ↓ 8 Changed at 2010-03-25T04:53:45Z by 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.
comment:8 in reply to: ↑ 7 Changed at 2010-03-25T05:14:30Z by davidsarah
- Resolution set to invalid
- Status changed from new to closed
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 :-)
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?