Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Add more details after talking with Jed.

...

  1. Split the long-term development in to logical pieces that can be checked in to master over timeas they are finished.
  2. Add pieces back to master with PRs as is done for mainline ACME development.
  3. Add a test or tests for your new feature.  These tests won't be added to the main acme test suites until the feature is "officially added".  They  If you have more then one, they could be part of a separate test suite.As you develop new pieces of your feature, run your tests to make sure mainline ACME development does not break your feature.   Run acme_developer on your branches to make sure you haven't broken the rest of ACME.  Your PR must still pass the standard ACME testing.
  4. Develop the next piece of your feature with a new branch from the head of master.

Feature is always in the ACME source but may not be fully working.  Once working and "officially added", test for that feature becomes part of standard test suite.

Long-lived

...

integration branch (for

...

2 or more related features)

  1. Create a clone of ACME-Climate/ACME that others can push to an integration branch which will track ACME master.   This is typically master on a fork of ACME such as https://github.com/ACME-Climate/ACME-ECP
  2. Each feature developed through small, focused branches, the PR for each branch merged to the master of the fork.
  3. Master of the fork is kept up-to-date with ACME Designate a person to maintain the integration branch.  They will update it with latest ACME master.
  4. Make feature branches off of this integration branch.  PR's should be made back to the integration branch.
  5. Before merging, test each PR individually using acme_developer plus additional tests for the feature before merging.
  6. If testing each PR each day costs to much, you should also make a "next" branch for the integration branch to test multiple PRs nightly.  This may also be necessary if you want more assurance the integration branch is stable.
  7. The maintainer can should make "mini releases" of the integration branch with a PR back to ACME-Climate/ACME.  (tag the integration branch to mark these).

Feature lives on the integration branch until integration branch is merged to master.

Long-lived branch

...

off of ACME-Climate/ACME master (or from an integration branch)

  1. Start a branch for your development from ACME-Climate/ACME like normal ACME development.
  2. Make a test or tests for your feature
  3. Keep your branch up-to-date
    1. PREFERRED: Periodically rebase your branch to the head of master (or head of
    master.
  4. Run your test on the rebased branch to make sure everything still works.
  5. Also run
    1. the integration branch)
    2. OR you can merge master to your long-lived branch IF AND ONLY IF:
      1. A subroutine or function your feature depends on has changed its API OR
      2. A tag has been made on ACME master (so you get a known state).   Do NOT make random "oh its been a while" merges of master to your branch.
  6. Run acme_developer on your branch to make sure you haven't broken other parts of ACME.

...

  1. along with tests for your feature as development proceeds.

Features lives on your branch until it is finished.