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

[hendrik]

On Wed, Aug 26, 2009 at 05:18:43AM -0400, Stephen Leake wrote:
> Thomas Keller <address@hidden> writes:
> 
> > So I think now that this change is in nvm, we should start dealing with
> > that. I see basically three options:
> >
> > a) We don't care at all about netsync breakage. After all there *is* a
> > reason why we have no 1 as major version number... If you find this
> > unfair towards bigger projects, ok, then lets make a 0.44.x branch and
> > split up the development here. If people want the new features, they
> > have to upgrade, if not, we promise that we fix critical bugs for the
> > 0.44.x line for at least the additional time we see projects using the
> > old client. Since this is a rather small community and monotone hasn't
> > seen many critical bugs in its history, I think this is managable.
> 
> This is a good fall back plan.

It's quite clear to me that unless the new monotone can handle both 
protocols (or I keep two monotones around) I'm going to have trouble 
syncing with everybody I have to sync with.  Not enormous trouble, mind 
you.  I have control over the versions of monotone used by the servers 
in all but one of the projects I'm involved with, so I can just choose 
the moment of migration carefully.  If I were to be only a client for 
more than one project, it would be more difficult.  Even if I had to 
sync with multiple external servers, and my distro were balky about 
multiple monotones, I can use the multiple machines I have and 
upgrade them differently, so that I could do sync'ing from whatever 
machine ran the right protocol.

But if protocol negotiation won't do the whole job (and it looks as 
if it may not) it would simplify my life immensely if the protocol to 
use were made a command-line parameter on the mtn sync command.  We 
could even store a default value of this parameter in the _MTN directory 
after a successful sync.

Such a command-line parameter would cut down on the number of 
versions of monotone that have to be maintained, and would simplify 
getting it all through distro maintainers.  End users would have to be 
informed of the issues, though.

> 
> > b) We do not release 0.45 unless we have some netsync version
> > negotiation in place, like some people spoke about. I'm not quite sure
> > if /how this will seamlessly work with current mtn netsync versions,
> > because I don't see (from a glance over the netsync code) an easy way to
> > tell the user "hey, please upgrade to 0.45 - your client is too
> > old".
> 
> It would be nice if the 0.45 server could deal gracefully with older
> clients, and vice-versa, but it's not a requirement.

And there seems to be some question whether it's reliably possible to 
recognise older clients with the protocol they understand at present.

> 
> It _is_ a requirement that the 0.45 server and client be able to deal
> gracefully with any future client or server, even in the case of
> another netsync protocol change.

And that we cen design in now.

> 
> > c) We do not release 0.45 unless we made the server part accepting the
> > pre-0.44 client requests. This seems to be related to b) in the way that
> > at least the server has to somehow figure out what kind of client speaks
> > to him, but as a start we could maybe say "no version field -> pre 0.44,
> > version field available -> 0.45 or later".
> 
> This is a good goal, but I don't think it needs to be a requirement.
> 
> -- 
> -- Stephe
> 
> 
> _______________________________________________
> Monotone-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/monotone-devel