When to add flags to network status vs adding new items

[Nick Mathewson]

On Sun, Dec 17, 2006 at 03:24:18AM -0500, Roger Dingledine wrote:
> On Sat, Dec 16, 2006 at 09:03:17PM -0500, Nick Mathewson wrote:
 [...]
> > I'd like to reserve flags for things deduced by the authorities, and
> > include the first part of the platform string (i.e., "Tor
> > 0.1.2.4-alpha") in the networkstatus for each router.
> 
> Sounds good to me. Where in particular should we put it?

In the networkstatus, as a new line in the routerstatus section,
something like "opt v".

 [...]
> Are we talking one version to describe everything, and we increment it
> every time we add a new feature? If so, that pretty much forces other
> implementations to build things in the same order we did. Or if we're
> talking a bunch of different version numbers for each subsystem, how do
> we decide which subsystems to version, and how do we avoid bloating the
> networkstatus with O(n) version numbers?
> 
> Fortunately, we can get away with just using Tor version numbers for now,
> since we're the only existing server implementation of the Tor protocol.
> I vote that we stick with the easy answer for now, and if we need to get
> more complex later then at least we'll know more about our constraints
> at that point.

We need to design something sensible when we do the protocol redesign,
so for now here's what I propose (copied from our mtg on Monday so
that or-dev gets some closure):

For now, we use Tor versions, in the format "opt v Tor
0.1.2.5-alpha".  This will work until we do the protocol versioning
design.

To get forward compatibility, let's say that if the initial keyword on
the line isn't "Tor", the versioning design update has happened, so
current implementations should assume that the version of such a
server is newer than any they know about.  Later versions of Tor can
be made to understand current version numbers.

yrs,
-- 
Nick Mathewson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20061220/513216f2/attachment.pgp>