[Unison-hackers] Re: a common patch set - first attempt [repost]

[Andrew Schulman]

> I can imagine two reasons why people might 
> think of doing this: (1) because they only want to install updates on 
> one host and have it communicate with another host running an 
> (unpatched) old version,

This is the nub of the problem for me as a packager.  The reality is 
that many sites and even OSes are slow to upgrade from old versions.  
Debian, for example, until very recently only offered version 2.9.1.  It 
now also offers 2.10.2, but only in unstable; the stable (Sarge) and 
testing versions are both 2.9.1, and Sarge, having just been released, 
is going to be with us for a long time.  

Now because of Unison's version constraints, if a user wants to 
synchronize with a server running 2.9.1, then their only choices are to 
either run 2.9.1 on their client, or else build and install a later 
version themselves on their server.  For me as a packager, the whole 
point of providing a package is to save people the work of having to 
build and install their own versions.  So, in order to allow Cygwin 
users to synchronize with servers running old versions, I have to 
package those versions for Cygwin.  This is why Cygwin now includes four 
Unison packages: unison2.9.1, unison2.9.20, unison2.10.2, and 
unison2.12.0.

This doesn't mean that you should have to maintain and patch 2.9.1 and 
2.9.20 forever.  At some point they can be declared no longer supported.  
But just the Debian problem alone suggests that this may take much 
longer than we'd like, and in general the version constraint means that 
the burden of maintaining old versions is always going to be 
higher.  At least versions 2.9.1, 2.10.2, and 2.12.0 are likely to be 
in use for quite a while yet.

Andrew.