I like this diagram which illustrates what we're trying to achieve with this scheme.
This shows what a git tree would look like using this workflow. Below are what happened during each stage.
Commit A-C: Made on branch 0.10.0
Commit D: Made on branch 0.10.0, tagged as rc1, new 0.11.0 branch is created
Commit E-F: New features added to 0.11.0 branch
Commit G: Bug fix on 0.10.0 branch, immediately merged into 0.11.0 branch
Commit H-I: New features added to 0.11.0
Commit J: Test added on the 0.10.0 branch, immediately merged into 0.11.0, tagged as 0.10.0 release
Commit K-L: New features added to 0.11.0
At this point, all development and testing should be done on 0.11.0. It's possible at some point bugs will be found on the 0.10.0 release. Depending on the priority of bug, we can either punt the bug to spin 11 and the fix goes on the 0.11.0 branch, or if it's critical, we can create a new 0.10.1 branch off of 0.10.0 and do the same process while merging fixes into 0.11.0.
1 Comment
Mike Beckerle
I like this diagram which illustrates what we're trying to achieve with this scheme.
This shows what a git tree would look like using this workflow. Below are what happened during each stage.
Commit A-C: Made on branch 0.10.0
Commit D: Made on branch 0.10.0, tagged as rc1, new 0.11.0 branch is created
Commit E-F: New features added to 0.11.0 branch
Commit G: Bug fix on 0.10.0 branch, immediately merged into 0.11.0 branch
Commit H-I: New features added to 0.11.0
Commit J: Test added on the 0.10.0 branch, immediately merged into
0.11.0, tagged as 0.10.0 release
Commit K-L: New features added to 0.11.0
At this point, all development and testing should be done on 0.11.0.
It's possible at some point bugs will be found on the 0.10.0 release.
Depending on the priority of bug, we can either punt the bug to spin 11
and the fix goes on the 0.11.0 branch, or if it's critical, we can
create a new 0.10.1 branch off of 0.10.0 and do the same process while
merging fixes into 0.11.0.