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

[Benjamin Pierce]

Hi Jerome,

> I'm in favor of option (4), and actually I don't really understand
> what overhead you are talking about: improvements would be done in the
> "trunk", just as now.

Perhaps I haven't understood exactly what you have in mind.  I thought 
proposal (4) would mean making a branch in the repository for each of 
the old versions (2.9.1, 2.10.0, etc., etc.) and, whenever a bug was 
fixed in the trunk, remembering to propagate the change to all of these 
branches.  If we're just talking about a "new development" trunk and a 
"bug fixing in most recent stable version" branch, then that's easier 
to deal with.  There's still a little more work for someone fixing a 
bug (compared to just fixing it for future versions), but as you say it 
is easier than doing the same thing with patches.

Someone will need to do a little hacking to implement this development 
model: Currently, every new svn commit ticks the minor version number, 
but we'd now want to do this just on the development trunk, not on the 
bugfix branch.

> But I think the right question is what development model we want for
> Unison.

I agree completely.

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

One point that I do not understand yet is whether people have 
compelling reasons for wanting to compile patched variants of very old 
versions (like 2.9.1).  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, and (2) because they might consider a later 
change to be a downgrade (e.g., when we added resource fork support, I 
think some people were unhappy because things that used to work 
partially, but well enough for them, were turned into error 
situations).  But I hope this is not a major need for many people.

>
> For a long time, we had only one branch where both bug fixes and new
> features were committed.  Also, we made few releases as it required a
> lot of work.  I think this did not work that well, as it took a very
> long time for bugs to be fixed in a stable release, and by the time
> they were fixed, new bugs were also added.  (There was no bug
> resulting in data loss though, which shows how well Unison was
> designed by Benjamin.)

And you and Trevor!!!

Regards,

       - Benjamin