Zack Weinberg schrieb: > On Tue, Aug 25, 2009 at 11:17 AM, Ludovic > Brenta<ludo...@ludovic-brenta.org> wrote: >> Richard Levitte <rich...@levitte.org> writes: >>> stephen_leake> I agree; we should hold the next monotone release until >>> stephen_leake> netsync version negotiation is supported. >>> >>> So now, all we gotta do is hack that as good and fast as we can? >>> >>> Cheers, >>> Richard ( it won't help current clients anyway, will it? ) >> Yes, it would; a client built from today's n.v.m head cannot speak to a >> server running on a long-term-support operating system such as Debian >> stable. Not can it speak to any other client a week old, for that >> matter. > > This is bad enough that we might want to consider reverting the > keys-by-hash change until we have protocol negotiation in place, > however we wind up doing that.
As the current release manager I haven't yet spoken up just because I've seen a lot of other people with lots of good arguments for either case and I haven't had to add much to them. However, I strongly oppose to revert the current work from Timothy in nvm, just because this would put this particular, very useful change back on a work bench where it is easy to get forgotten about. There are no other big changes sitting in 0.45dev which would need an immediate release, so I also have absolutely no rush releasing 0.45, say, next week. 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. 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". 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". Again, I still think its *good* to have this change in nvm - even if this makes the next release take a little longer. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel