Confirmed users
4,971
edits
No edit summary |
|||
| Line 17: | Line 17: | ||
** Two repositories breaks this; to determine source for any particular time or build requires additional tools/mapping | ** Two repositories breaks this; to determine source for any particular time or build requires additional tools/mapping | ||
** The fastest solution to map a mobile change with a specific m-c change (and vice versa) is to merge in. | ** The fastest solution to map a mobile change with a specific m-c change (and vice versa) is to merge in. | ||
== Improved branching mechanics == | == Improved branching mechanics == | ||
| Line 54: | Line 42: | ||
** Similarly, risky patches [landed in other branches] need not be taken in a branch until they have time/headspace to refresh the code base. | ** Similarly, risky patches [landed in other branches] need not be taken in a branch until they have time/headspace to refresh the code base. | ||
** This is a corollary to avoiding "moving target" integration. | ** This is a corollary to avoiding "moving target" integration. | ||
== Straightforward release branching == | |||
=== Faster release cycles === | |||
* When dealing with fast release cycles, sometimes you need to make fast branching decisions | |||
** The lack of separation between branches adds complexity to these decisions | |||
** Needing to freeze not one, but two branches adds strain on the various teams | |||
=== Risk minimization === | |||
=== Multiple concurrent releases === | |||
== Reduced mobile-specific support overhead == | == Reduced mobile-specific support overhead == | ||