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

[hendrik]

On Mon, Aug 24, 2009 at 06:08:43PM -0500, Timothy Brownawell wrote:
> On Mon, 2009-08-24 at 09:58 -0400, address@hidden wrote:
> > On Mon, Aug 24, 2009 at 12:06:12PM +0200, Ludovic Brenta wrote:
> > > Hello,
> > > 
> > > I am of the opinion that the next version of monotone should be 1.0 
> > > because of
> > > the netsync flag day.
> > > 
> > > This would allow us, maintainers of monotone in Debian, to provide two
> > > versions of monotone in parallel: monotone (the latest) and monotone0 
> > > (0.44),
> > > or monotone1 and monotone.  This would allow people to have both versions
> > > installed at the same time, without a clash.
> > > 
> > > I think this would be desirable because Debian 5.0 "Lenny" contains 
> > > version
> > > 0.40, runs on many servers including www.ada-france.org, and will remain 
> > > in
> > > service for at least another two years.  Thus the transition period for 
> > > the
> > > netsync change cannot be shorter than that.
> > 
> > I suppose the other option would be for monotone to detect which 
> > versions of netsync are available at the other end, and use whichever is 
> > the most recent.  That way you could upgrade and still be compatible 
> > with those who haven't.  Whether this is technically feasible (is enough 
> > information available in the data base to support both protocols? 
> 
> All the same information is there, but the cert hashes have changed. I
> suppose the old hash could be stored in the db as well...
> 
> It's now possible to have multiple keys with the same name, so incoming
> old-format certs could be ambiguous. I suppose they could be
> disambiguated by trying to verify the signature with each of the keys
> with that name.
> 
> >  Does 
> > the netsync protocol have a version-number field somewhere in an early 
> > packet?) I don't know.
> 
> The packets all have a version field, but there's nothing to allow for
> negotiation. The server sends the first packet, so the clients would all
> have to be upgraded first.

So this time around we're stuck.  Well, not entirely.  I suppose it *is* 
possible for a development group to upgrade all their clients first...  
And I suppose we could leave a monotone server that serves the 
new-protocol monotone source code running on the old protocol so that 
people are capable of upgrading.

But could we install negotiation in the new protocol we're introducing 
now so that next time around we have a chance of avoiding this mess?  
There will be even more monotone users out there by then.  I don't think 
we want monotone to end up like gnutella, which treats the use of an 
obsolete client as an attack.

That's something I learned years back when I was implementing OSI 
protocols.  Always negotiate the protocol version.

-- hendrik