Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0

[hendrik]

On Wed, Aug 26, 2009 at 12:52:52PM -0400, Ethan Blanton wrote:
> Derek Scherger spake unto us the following wisdom:
> > One discussion that we've had before centers around protocol version numbers
> > verses specific features. Iirc SMTP's EHLO command may respond with a list
> > of keywords indicating the various optional features that a particular
> > implementation supports.
> > 
> > Personally, I think I prefer this scheme over a simple version number check.
> > It makes feature support explicit rather than implicit and up to the
> > respective parties to infer based on what protocol versions they find.
> 
> This makes more sense when you have multiple interoperating
> implementations based on different code bases or with differing
> requirements ... do you anticipate that there will be multiple
> implementations of netsync which need to negotiate individual
> features?  If not, it's just extra complexity.

That's the main reason why things like the OSI session protocol (which I 
still think is one of the more useless protocols on the planet) had a 
whole suite of options -- different implementations might have different 
availabilities.

But there's another reason for having options, even with only one 
versino of one implementation.  A given installation may decide to 
restrict a particular feature for policy, administrative, or security 
reasons.  Then netsync would have to negotiate accordingly.  But I'm not 
sure this is a realistic situation for the present, and there's the risk 
that an option notation we choose now may not be sufficiently 
future-proof.

We can use a simple version number check for now.  If we ever want a set 
of optional features (have I got this right?) we can bump the version 
number and everyone who understands that version number will know to 
check for optional features.

In any case, even if we do have a set of optional features to negotiate, 
I'd still argue keeping the version number as well, because we'd have 
to bump it if we ever needed a new coding for the optional features.

Anyway, what I've been proposing here is the minimum that's necessary 
for us to be able to negotiate protocol versions in the future.  A sort 
of protocol ID bootstrap, as it were.  And that's a version number.  
(actually, one bit would do, but that's probably unnecessarily compact, 
and not as convenient if you have more than one protocol change.) 

-- hendrik