Next focus: PROCESS

[Andrei Alexandrescu]

On 12/16/12 11:56 AM, foobar wrote:
> I don't see why that is a requirement (having a branch per release).
> We can still have a single stable branch with tags for releases and when
> Walter needs to provide special customizations he can always just branch
> off of the tagged release.

To the extent possible, a good process should facilitate the desirable 
scenarios. Clearly this is possible, but that doesn't mean we shouldn't 
make it easy within reason.

> This should be Walter's business and not part
> of the "official" community process.

I think this is rather shortsighted. Corporate support by Walter is only 
one possible scenario, but there are many others.

> in git terms, assuming we have a tagged release of 2.61
> $ git checkout -b 2.61-partner 2.61
> This branches off a new branch "2.61-partner" for the specific partner
> modification based off the contents of the "2.61" release.
>
> Also, this kinda messes with the notion of integration. A single stable
> branch helps prevent "forgotten" bug-fixes. I.e a critical bug was fixed
> on release N, what will ensure it will be included in release N+1? If
> Release N+1 is on the same branch than the bug-fix is included by
> default and prevented the need to perform a manual operation (a merge)
> that could be forgotten.

The prevalent use of the feature would be that a bug in a future release 
is back-patched onto an older release.


Andrei