| | 59 | == Naming rationale == |
| | 60 | |
| | 61 | '''Question:''' Is {{{develop}}} tracking {{{master}}} and {{{latest}}} tracking {{{develop}}} a typo or inconsistency? |
| | 62 | |
| | 63 | * Branch "master": Latest Boost release. |
| | 64 | * Branch "release/n.n.n": Release preparation branch. |
| | 65 | * Branch "develop": automatically tracks "master" of submodules (scripted). |
| | 66 | * Branch "latest": automatically tracks "develop" of submodules (scripted). |
| | 67 | |
| | 68 | '''Answer:''' |
| | 69 | |
| | 70 | No, it is not. Super "develop" does track sub "master", and it does seem inconsistent, at first. |
| | 71 | |
| | 72 | Start from the git flow workflow and the role it assigns to the "master" branch. A commit to "master" is a release, by definition. And commits to master (releases) are done by merging. Let's suppose, for simplicity, that it is "develop" that is merged to "master", and not a dedicated release branch - the latter just adds one more level of indirection. |
| | 73 | |
| | 74 | So "master" is the last release, and "develop" is the next release (or the next next release, if a release branch is active). |
| | 75 | |
| | 76 | Now... if a commit to the "master" branch of the super-project is a release by definition, it follows that it cannot be scripted to track submodules, right? The "master" branch of the super-project will only contain merge commits from the super-project "develop" branch (or, in practice, a super-project release branch, which will be what "develop" was at some earlier point in time.) |
| | 77 | |
| | 78 | Consider now a submodule, smart_ptr. Applying the logic above, smart_ptr:master is the last release of smart_ptr, and smart_ptr:develop is the next release of smart_ptr. The last release of smart_ptr (smart_ptr:master) will become part of the next release of Boost (which lives on boost:develop). |
| | 79 | |
| | 80 | Hence, boost:develop can, and should, be scripted to track smart_ptr:master. |
| | 81 | |
| | 82 | This all falls out of the asynchronous release schedule of the submodules with respect to the super-project. |
| | 83 | |
| | 84 | In addition, Peter proposes an additional super-project branch ("latest") that does track the submodule "develop" branches, purely for testing purposes. It's never merged to anything, no release branches are ever spawned off of it; it's just the integration test that is the equivalent of our old SVN trunk test. |
| | 85 | |
| | 86 | It's basically a three-level architecture: |
| | 87 | |
| | 88 | * submodule:develop |
| | 89 | * submodule:master == super-project:develop |
| | 90 | * super-project:master |
| | 91 | |
| | 92 | which, if we used a single repo for all of Boost, would have been achieved with having a permanent "feature" branch per component: |
| | 93 | |
| | 94 | * boost:feature_smart_ptr |
| | 95 | * boost:develop |
| | 96 | * boost:master |
| | 97 | |
| | 98 | The workflow is more or less the same in either case - upper levels merge to lower levels when stable. |
| | 99 | |
