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
