Thomas Keller <[email protected]> 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 _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
