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

[Stephen Leake]

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.

> 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.

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.

> 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