github.com/cloudfoundry/cli@v7.1.0+incompatible/doc/adr/0010-v7-and-v8.md (about)

     1  # 10. Synchronizing V7 and V8 (Master) code
     2  
     3  Date: 2020-06-04
     4  
     5  ## Status
     6  
     7  Submitted
     8  
     9  ## Context
    10  
    11  _The issue motivating this decision, and any context that influences or constrains the decision._
    12  
    13  **Current**: Changes committed to the [V7
    14  branch](https://github.com/cloudfoundry/cli/tree/v7) need to be cherry-picked
    15  onto the [master (V8) branch](https://github.com/cloudfoundry/cli), a manual
    16  process.
    17  
    18  This depends on the pair to remember to cherry-pick. If forgotten, the commit
    19  will not be merged, and we run the risk of bugfixes (and features) not
    20  manifested in both branches.
    21  
    22  ## Decision
    23  
    24  _The change that we're proposing or have agreed to implement._
    25  
    26  Commit changes on the v7 branch then merge to master/v8, e.g.:
    27  
    28  ```bash
    29  git co v7
    30  git pull -r
    31   # make changes
    32  make
    33  git add -p
    34  git ci
    35  bin/push.sh
    36  ```
    37  
    38  [`push.sh`](https://github.com/cloudfoundry/cli/blob/master/bin/push.sh) is a
    39  scripts which pushes the v7 commit, rebases against master, checks out master,
    40  pulls, merges v7, pushes, and then checks out v7. It automates some of the more
    41  tedious aspects of the commit cycle.
    42  
    43  This is the process that Ops Manager follows to maintain several branches.
    44  
    45  It is not without drawbacks, though. Here are the notes from the Ops Mgr anchor:
    46  
    47  > We're still using merge forward as the primary method of sharing features / bug fixes across all of our releases. It generally still works well for us, but there are drawbacks.
    48  > * If you care about a "clean", fairly linear git history for each branch. The merge commits can definitely make things difficult to follow sometimes. This isn't much of an issue for us, but I can imagine it being more important for ya'll since it's an open source project
    49  > * It assumes that everything in the earlier branch belongs in the later branch. This makes a lot of sense for common bug fixes, but perhaps there are feature differences that could make it trickier in your case.
    50  > * It somewhat discourages large refactors or cleanups. In 2.7 we did a major refactor of our React code, so anytime we need to do a UI bug fix in 2.6 or below, it becomes a pain to merge forward and we basically have to re-do the work. (Though this probably would apply to a cherry-pick strategy as well!)
    51  > I think for Ops Manager, since we're maintaining so many branches at once, and the fact that most of what we would do on earlier branches is bug fixes for ALL branches, it's slightly less overhead for us to do merge forward. If the CF CLI is diverging in any significant manner between versions, and you're only going to be dealing with 2 versions, cherry-picking from one branch to the other might be cleaner. Merge forward should still work, but maybe you'd be getting less benefit out of it.
    52  
    53  ## Consequences
    54  
    55  _What becomes easier or more difficult to do and any risks introduced by the change that will need to be mitigated._
    56  
    57  If a pair forgets to merge their commit to master, the subsequent merge to
    58  master will pick up that change (this is a good thing).
    59  
    60  Sometimes a merge conflict will occur. This happens with cherry-picks, too.
    61  
    62  The first merge will entail duplicate commits (the ones that have been
    63  cherry-picked).