github.com/cloudfoundry/cli@v7.1.0+incompatible/doc/adr/0002-develop-v6-and-v7-on-master-simultaneously.md (about)

     1  # 2. Develop v6 and v7 on master simultaneously
     2  
     3  Date: 2018-09-25
     4  
     5  ## Status
     6  
     7  Accepted
     8  
     9  ## Context
    10  
    11  _The issue motivating this decision, and any context that influences or constrains the decision._
    12  
    13  We have two teams developing the CLI. 
    14  One (CLI) is building out functionality (such as a better UAA and login experience) for the current, stable v6 releases. 
    15  One (VAT) is dropping compatibility with CAPI v2 to more quickly integrate with and build out CAPI v3. 
    16  VAT is doing so in v7 releases of the CLI.
    17  
    18  For the last three weeks, 
    19  VAT has been developing on a long-running _vat_ branch based on v6.39. 
    20  Part of the goals for VAT include 
    21  incorporating all 7-10 new epics that will be built on _master_,
    22  along with sharing any bugfixes back and forth between the two branches.
    23  VAT has been tracking which commits should be cherry-picked back and forth each day, 
    24  resulting in significant overhead and bookkeeping.
    25  Rather than continuously merging two long-running branches into each other, 
    26  the VAT team proposes to develop on _master_ simultaneously with CLI.
    27  This would allow the CAPI v3 acceleration work to proceed faster.
    28  
    29  The CLI team is constrained by needing to continue shipping stable versions of v6. 
    30  There would be increased risk of shipping unstable versions, 
    31  given that the VAT team's work involves modifying existing code
    32  for which there are no integration tests.
    33  The VAT team would bear little of this risk
    34  and would reap most of the benefit.
    35  
    36  ## Decision
    37  
    38  _The change that we're proposing or have agreed to implement._
    39  
    40  VAT is proposing to have both teams develop in the _master_ branch simultaneously.
    41   
    42  One code base would be building two different versions of the binary.
    43  The v6 binary would not include any v7 actors or commands.
    44  Integration tests will need to split to represent v6 behaviour vs v7 behaviour.
    45  We will need two separate command lists.
    46  The main.go file can either be copied as two separate packages 
    47  or as a single file that relies on go build flags to determine the version.
    48  Any v6 commands that are already backed by v3 endpoints will need to be carefully dealt with
    49  in order to ensure backwards compatibility when working with the v6 CLI.
    50  Several packages are differentiated by a v2/v3 prefix,
    51  but should be v6/v7 going forward to avoid confusion.
    52  Removal of v3 prefix commands from the v6 CLI to reduce overlapping surface area.
    53  
    54  ## Consequences
    55  
    56  _What becomes easier or more difficult to do and any risks introduced by the change that will need to be mitigated._
    57  
    58  The v7 CLI will automatically gain all new features, bug fixes, etc., from the v6 CLI.
    59  When VAT makes fixes to the CLI as a whole (e.g. solving a race condition in a test),
    60  the CLI team automatically gains that benefit.
    61  There is less risk of dropping commits that should be shared.
    62  It will be easier for each team to restructure the code base (or even rename files) and continue to share code.
    63  
    64  There is an increased risk of blocking each others' pipelines.
    65  There is an increased risk of inadvertently shipping breaking changes in the v6 CLI.
    66  There is going to be confusion as to which team owns which section of the code.
    67  The integration test structure could become difficult to work with, especially as the two products drift apart.
    68  
    69  The teams can still decide to branch/fork in the future if this proposal becomes untenable,
    70  however, branching/forking now will make it nigh-impossible to merge in the future.