[tahoe-dev] version advertisement and negotiation

zooko zooko at zooko.com
Thu Nov 13 21:00:44 UTC 2008


DrewP wrote:
 >
 > > Next, I hope you're considering the presence of non-allmydata
 > > nodes out there. Your server version number shouldn't be
 > > "1.2.0r1234", since you're then inviting each new server to invent
 > > its own new scheme for versioning.  At least use
 > > "allmydata-1.2.0r1234".

Brian wrote:
 >
 > Yeah, that's my biggest reason for preferring the "Protocol Version"
 > numbers as the primary factor.

Agreed.

 >  We've already had problems with the "1.2.0r1234" scheme becoming
 > non-monotonically-increasing, since the Allmydata windows client
 > product that incorporates Tahoe is labelled "3.0.0" (since it
 > followed the non-Tahoe-using client named "2.0"), and due to the
 > slightly weird way that we've been building the windows executable,
 > the tahoe node itself advertises the same 3.0.0 version. So now we
 > have tahoe 1.3.0 being more advanced than something that claims to
 > be tahoe 3.0.0 .

 > My feeling is that a version string (as opposed to a number) is
 > always going to be susceptible to pressures of marketing, etc. Zooko
 > and I have gone back and forth about this a bit..

I think you are mis-diagnosing this. We would have had the same
problem if the values had been "1" and "3" as when they were "1.2.0"
and "3.0.0".  We would not have had the problem had they been
"tahoe-lafs-1" and "allmydata.com-3", nor if they had been
"tahoe-lafs-1.2.0" and "allmydata.com-3.0.0".

I don't think we can rely on marketers of Tahoe products to use
strings poorly but numbers well.  Instead of trying to define a format
which marketers won't mis-use, how about we let marketers call it
whatever they want as long as it starts with "$their-product-name"?

So concretely, I propose that the application version string begin
with the application name, and otherwise stay the same.

This is probably good enough because, per the rest of the discussion,
the application version string is not the primary field for protocol
negotiation -- it is just there to fall back on if you know more about
a specific application version than it knows about itself.

I'm making good progress on checker/verifier/repairer, and aside from
that the only technical change that I think we need before Tahoe-1.3.0
is a good plan for versioning.

Regards,

Zooko




More information about the tahoe-dev mailing list