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

[Ethan Blanton]

Thomas Keller spake unto us the following wisdom:
> 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.

As a member of one of the large projects using monotone (Pidgin), this
seems OK to me.  The fact that monotone does not require any support
libraries/etc. means that dealing with version skew across
servers/projects is as simple as 'cp /usr/local/bin/mtn
/usr/local/bin/mtn0.44' before 'make install'.

In fact, we already do this, so that our downloadable bootstrap
database will work for users of Debian Lenny.  It is created by
/usr/local/bin/mtn-0.39.  :-)

As I type that, it does occur to me that this means that our
downloadable bootstrap db will *have* to upgrade, as we will no longer
be able to use netsync to "backport" the db format.  I don't think
this is an earth-shattering loss, though.  Frankly, anyone who is
serious about using monotone is using something post-0.40 anyway, for
the various speedups.

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

Either of these would, of course, be superior -- but I think a) is
sufficient if push comes to shove.

That said, don't rush an 0.45 on our account.  I know I have
complained early and often about the key ID thing, and it is indeed a
problem for us, but a few weeks or even months won't make a huge
difference.

> Again, I still think its *good* to have this change in nvm - even if
> this makes the next release take a little longer.

Agreed.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
                -- Cesare Beccaria, "On Crimes and Punishments", 1764

signature.asc
Description: Digital signature