Hi all,
I am looking for ideas for implementing a new revised branching strategy for my codebase. I've read a number of white papers and haven't yet come across anything that I feel truly solves the problems I face.
I am working on a number of applications, each that have separate release schedules and releases. These applications have a number of common projects that they all share (and reference) - all of my applications make use of atleast one of these common projects.
I use Bzr (Bazaar) as my source control tool and have employed a Per-Release branching strategy since day one - each branch has the ENTIRE codebase - including common code.
Fast forward to today, I have this structure:
My issue is, imagine I have 10 applications (vs only 2 shown above), I find a bug in common code in app2 v1.0, and need to fix it.
I fix it in app2 v1.0 and release a bug-fix version. I merge this to trunk so future releases won't get affected by the same bug. However, I still have all my other applications potentially affected by this bug... I cannot merge trunk into the release branches since that will infect the released branch with newly, potentially untested changed (yet to be put through QA etc).
The only way I can do it is by copy-pasting the fix into all my other ten application release branches to ensure that no other change gets through (as I don't want any changes to destabilise my release branch).
I'm not looking to be spoon-fed the solution, just some helpful hints or some pointers to other issues regarding how I'm working.
Thanks,
I am looking for ideas for implementing a new revised branching strategy for my codebase. I've read a number of white papers and haven't yet come across anything that I feel truly solves the problems I face.
I am working on a number of applications, each that have separate release schedules and releases. These applications have a number of common projects that they all share (and reference) - all of my applications make use of atleast one of these common projects.
I use Bzr (Bazaar) as my source control tool and have employed a Per-Release branching strategy since day one - each branch has the ENTIRE codebase - including common code.
Fast forward to today, I have this structure:
Code:
key: ==> is a merge
trunk
|
| ==> app1 v1.0
| |
| <=== X - bug fixes to app1 code.
| |
| o - end of life for app1 v1.0
|
|
| ==> app1 v2.0
| |
| ... - ongoing bug fixes and support for app1 in this branch
|
|
|
| ==> app2 v1.0
| |
| |
| <=== X - bug fixes to app2 code.
| |
| |
| ? - bug in COMMON libs here
|
|My issue is, imagine I have 10 applications (vs only 2 shown above), I find a bug in common code in app2 v1.0, and need to fix it.
I fix it in app2 v1.0 and release a bug-fix version. I merge this to trunk so future releases won't get affected by the same bug. However, I still have all my other applications potentially affected by this bug... I cannot merge trunk into the release branches since that will infect the released branch with newly, potentially untested changed (yet to be put through QA etc).
The only way I can do it is by copy-pasting the fix into all my other ten application release branches to ensure that no other change gets through (as I don't want any changes to destabilise my release branch).
I'm not looking to be spoon-fed the solution, just some helpful hints or some pointers to other issues regarding how I'm working.
Thanks,
Last edited: