add version info to t=JSON output data

[warner]

It will probably make life easier in the future if we add a version number to the JSON output from operations like deep-stats, deep-manifest, and deep-check.

A related piece would be to tell developers that they should tolerate the presence or absence of each field.

On the other hand, the only customers of the t=JSON are:

1) The Tahoe CLI
2) Tools written to use the webapi functions

I'm ok with requiring that you use e.g. a 1.3.0 CLI with a 1.3.x backend instead of a 1.4.x backend, and developers have to play catchup all the time anyways. So I'm not sure how much energy I want to put into this.

[freestorm]

It will probably make life easier in the future if we add a version number to the JSON output from operations like deep-stats, deep-manifest, and deep-check.
A related piece would be to tell developers that they should tolerate the presence or absence of each field.
On the other hand, the only customers of the t=JSON are:
1) The Tahoe CLI
2) Tools written to use the webapi functions
I'm ok with requiring that you use e.g. a 1.3.0 CLI with a 1.3.x backend instead of a 1.4.x backend, and developers have to play catchup all the time anyways.
So I'm not sure how much energy I want to put into this.

[freestorm]

I create a patch with tahoe version.

[zooko]

Thank you! It looks fairly good. I'm going to examine it more closely. While I'm doing so, please also write a unit test, probably in src/allmydata/test/test_web.py which calls the Python API methods that you changed. Actually there are already tests that call those methods, so find those tests and add a check of the version field to each one. For example, you changed directory.py ManifestResults to have a version number. I can see from directory.py line 475 that ManifestResults is created when you send a POST with certain arguments. Looking around in the tests, I find allmydata.test.test_web.Web.test_POST_DIRURL_manifest, which exercises that POST. So I think you can add a check inside test_POST_DIRURL_manifest() that a version string is present. You can tell when you're done because there is a unit test which goes red whenever you comment-out each of the lines of code that you've added in your patch.

I'm glad you are contributing to this! It is a "forward-compatibility" issue, which always makes me feel good about getting it completed and deployed in a new version of Tahoe-LAFS. Hopefully we can get it into v1.7.

[davidsarah]

I'm not sure that the Tahoe version is necessarily what we want for forward-compatibility (although it might be useful if we later find a bug in particular Tahoe versions that clients have to work around). My impression was that the description was referring to a version number that is updated whenever the output from each particular operation is changed.