> > 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 _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
