[tahoe-dev] version advertisement and negotiation

[Brian Warner]

>  > 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".

My thoughts are that a single integer is not sufficiently flexible to make
the marketeers happy: since an int isn't big enough to be sexy (or include a
trademark, or advertising, or a URL, etc), they will be forced to add their
own version string somewhere else, one which *is* big enough for their
purposes. We can constrain them into leaving our field alone :).

Even "1.2.0" (which has no company name in it) is a marketing version, in a
sense. We are using the various fields to communicate non-technical
information to the reader: our feelings about the stability of this release,
how big of a change it represents relative to the previous release, what sort
of compatibility issues they should expect to deal with, etc. These are
useful things to convey, but not in a protocol specification.

We can explicitly define the application version as being up to the packager,
and not establish any expectations of machine-readability.

> 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"?

Eh, I'm mostly ok with that, but I expect that the string won't be parseable
or unique, so I'd rather put the things we want to be parseable and unique
somewhere else. But, as you say, this is probably good enough, because this
string is just a fallback for other purely-protocol-driven fields.


cheers,
 -Brian