Different versions of Unison won't talk to each other. For example, if I have version 2.10.2 (current beta) installed on my local Cygwin host, I can't synchronize with a server that's running version 2.9.1 (current stable). The version numbers have to be exactly the same, or Unison will issue an error message and quit.
The reason for the incompatibility, as I understand it, is that Unison's archive format has changed from time to time. Data corruption could occur, or so I'm told, if a user tries to synchronize using versions of Unison that have different archive formats. In order to simplify their code, the Unison developers decided just to require identical version numbers before synchronization can take place. One can argue whether that decision was the right one, but that's the way Unison works at present.
The archive format is an on-disk thing, and not really relevant to network compatibility.
The reason for the (overly) strict initial version check is to avoid any need for versioning or compatibility in the protocol that follows the initial greeting.
Not that that changes the situation, of course. I'm just pointing out that the network protocol could be incompatible, even though archive formats on both ends were identical.
So the problem for Cygwin is how to accomodate these incompatible versions. There are probably two or three versions of Unison in common use today: 2.9.1 (current stable), 2.10.2 (current beta), and maybe 2.9.20 (previous beta). Others might come into use, however. There's the previous stable version (2.8.something), which is probably still running at a few sites, and there will probably be a new stable version released soon.
This leads me to two questions:
(1) How many of these different versions of Unison should I package? Of course, Cygwin doesn't have to provide every version. But I do want to provide the most commonly used ones, which might be anywhere from 2 to 4 versions.
More versions means that more people can use Unison, but also more archive storage space (unison-2.10.2-3.tar.bz2 is 400KB, unison-2.10.2-3-src.tar.bz2 is 515 KB), and more screen space in the setup utility taken up by almost-identical packages.
Another consideration is that Unison comes in both CUI and GUI (GTK2) versions. The current packages are CUI. I can't get the GUI version to work yet in Cygwin, but if I do this could _potentially_ double the number of Unison packages.
(2) If I'm going to provide just 2 or 3 versions, then should I split them into separate packages (e.g. unison2.9.1 and unison2.10.2), or keep them as previous, current, and test versions of a single unison package? The latter approach is what I'm doing now, with unison-2.9.20-1 and unison-2.10.2-3. It makes things simpler for users, but more complicated for the Cygwin admins (e.g. when I upload 2.10.2-4, I'll have to request that 2.10.2-3 be removed, and 2.9.20-1 be kept). It also prevents users from installing more than one version at a time-- which come to think of it is probably a good reason to split the packages.
Anyway, I'd appreciate some advice on these questions from either the Cygwin admins, or other maintainers who've tackled these issues before.
Debian seem to be packaging just the current stable 2.9.1.
I suggest following their example, and trying to convince the upstream maintainers that their current compatibility scheme is extremely packaging-unfriendly.
Max.
