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
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
