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

[Thomas Keller]

Zack Weinberg schrieb:
> On Tue, Aug 25, 2009 at 11:17 AM, Ludovic
> Brenta<address@hidden> wrote:
>> Richard Levitte <address@hidden> 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 | address@hidden | 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