[Openmcl-devel] making a git mirror of ccl

[Robert P. Goldman]

On 12/17/15 Dec 17 -6:04 PM, mikel evins wrote:
> 
>> On Dec 17, 2015, at 5:58 PM, R. Matthew Emerson <rme at clozure.com> wrote:
>>
>> If we were ever to convert completely to git, I would suppose that we'd want to maintain some sort of similar setup.
> 
> A very common git workflow is sort of the opposite: the master branch contains tested, vetted, working code, and another branch contains code being tested before merging it with the master. Branches are extremely cheap and fast to create and merge in git, and so it’s also very common for each dev to work on a distinct branch or, in fat, a collection of branches. It’s fairly usual to have one branch per feature being worked on, and for such branches to live only long enough for the feature in question to be developed and merged with the release.

That's really a "release-free" model, actually, where "master" == "release".

The branches that Mikel refers to are short-lived, "topic" branches, not
long-lived release/maintenance branches.

But in the case where you have a stable system that people rely on, like
CCL, you typically wish to have at least a "release" branch that
corresponds to the publicly released/shipped version.

And if people are depending on the released version, you may wish to add
patches to the released version at the same time that you are preparing
the next release.  In this case you will have two different tips of the
git graph.  This would be like maintaining "stable" and "testing"
simultaneously.

IIUC, SBCL does not have this behavior, and behaves as Mikel describes:
there's only one head, and a last release tag.  AFAICT, releases are
never patched as such (i.e., there's no "stable"), just tagged.  If
there's a bug in the latest 1.n.x it seems like you can either grab a
patch off head or wait for 1.n.x+1.  I don't believe they ever repair
1.n.x while preparing 1.n.x+1.

Put differently, the model Mikel's describing has release *tags* but not
really release *branches*.

I believe that CCL has always had release *branches*, and I actually
think that's a good thing, and there's no need to give it up when moving
to git.