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

[Trevor Jim]

On Jun 15, 2005, at 2:26 PM, Benjamin Pierce wrote:

> 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?

Hm, I haven't received that yet, not sure why.  Anyway...

I don't really have a problem with the status quo.
As a developer I'm perfectly happy running my own custom
version :-)

But as I understand it, this proposal does not address
what people are worried about, namely, the need to run
two different versions because they don't control both
ends, but they need some bug fix.  And, the proliferation
of patches.

In particular, under your proposal what happens if
someone desires a bug fix in an old stable version?
It doesn't say anything about this.

As a developer, I liked the old way: once a version
goes out, it never changes.  No patches to manage.
Every so often we declare a stable version.
That version could be identical to the previous
developer version, except for version number.
This seems strictly better than your proposal
(versions don't change underfoot).  Like your
proposal it does not address the different-version
interoperability issue.

-Trevor

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