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

[Benjamin Pierce]

I'm actually getting pretty persuaded that just using subversion to 
fork the repository is the best way to proceed.  What did you think of 
my last about this?

> The development model that I'd like to be in is something like this.  
> Most of the time, there are just two versions of Unison: a stable 
> version that is used by almost everybody and a development version 
> that is used just by developers and a few bleeding edge types that are 
> willing to help test new features.  Every so often, we make a 
> beta-release; when this happens, there is a period of a few weeks when 
> there are three versions: the old stable, the new beta, and the 
> developer version.  Once we're sure that the beta version is working 
> well (perhaps after fixing a few bugs, which we'd do without changing 
> its version number), it gets promoted to stable and we go back to the 
> standard situation with just two active versions.  I think we could do 
> all this pretty easily with subversion.  (After all this discussion, I 
> believe the main problem with our release process is precisely that we 
> never want to just promote the beta version to stable, because there 
> are almost always new bug fixes in the development version; so instead 
> we make a new beta release, etc.)
>

    - Benjamin


On Jun 15, 2005, at 1:51 PM, Trevor Jim wrote:

>> 1) Adopt a convention that, whenever anyone makes a change to a 
>> marshalled data structure, they bump the major version number, and 
>> make Unison's startup test just the major version number and ignore 
>> the minor version number.  This seems viable (especially since we 
>> have multiple people looking at commit messages and if one person 
>> forgets, someone else is likely to notice), and it has the great 
>> advantage of being simple.
>
> Like Jerome, I worry about your (1), I think it would be
> easy for a developer to miss the need for this.
>
> Maybe here is a slight improvement:
>
> Let's have a "protocol number" and require client
> and server to have the same protocol number.  All
> sessions start by checking this, using a sequence
> of messages that does not change even if the
> protocol number changes.
>
> Require all protocol messages to be registered before
> a session begins, using the "register" functions of
> remote.ml.  (Already true I believe.)  The register
> functions calculate a cumulative protocol number,
> a fingerprint of their arguments.  I don't know how
> to make this a true fingerprint given ocaml's
> current public interfaces, but for the moment let
> the fingerprint be MD5 hash of all of the protocol
> message names, plus a "datatypes number" that we
> bump whenever we change something that is outside
> of that (this part being essentially what Benli
> suggests).
>
> This isn't perfect but it buys us some automatic
> protection.  (And maybe Jerome or another ocaml
> insider can tell us how to get a better fingerprint.)
>
> The protocol number could be reflected in the version
> number, or not.  I actually prefer not.  I can
> conceive of a new major version that does not change
> the protocol; if we are trying to make different
> versions interoperable I don't know why we'd do that.
> Also, we are bumping the version number manually,
> and I think we all agree that a fully automated
> system would be best in the end; why require another
> manual step to get right.
>
> -Trevor
>
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at lists.seas.upenn.edu
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers