Versions Compared

Old Version 2

changes.mady.by.user Ralph Su

Saved on

compared with

New Version Current

changes.mady.by.user Hao Chen

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

This page to describe the branching model for ealge development. Basically, we adopt the branching model at http://nvie.com/posts/a-successful-git-branching-model/ with simplify.

 

Branching Model

Eagle branch model is a simplified version of aforementioned model.

...

  • Master branch : always stable, the last release version (the release means formal voted in eagle community)
    • E2E test and unit test should all passed
  • Release branches : There will be each branch for one official release. And a tag for each official release. After released, there should only two kind of commits happens in release branch:
    • Release related fix, e.g. want to release a bug fix based on release branch.  This fix would be released as a minor version, and merge to develop.
    • Documentation fix, this might continue after release.
    • E2e test and unit tst should all passed

Learn from calcite, release Release branch suggested naming: release-${releaseVersoin}, e.g. release-0.3.0-incubating; Tag naming: b, e.g. ealge-0.3.0-incubating branch-a.b which will be continuously used for following minor release like v{a.b.x}

Release tag suggested naming: v${a.b.c}

    1. For release candidate (rc), build tag with v${a.b.c}-rc${num}
    2. After vote for certain candidate passed, create as tag named v${a.b.c} without rc${num} postfix 
  • Hotfixes: named as hotfix-${issueNumber}, like hotfix-eagle-221. This is forked from master, must be merged to develop.
    • E2E test and unit test should all passed.
  • Develop Branch : named "dev" all active develop happens on here. Release branch cut out from here.
    • Unit test should all passed
  • Feature Branches : This is optional to apache/incubator-eagle. For most features, suggest contributor to fork code to their own repository, have their feature branch. Then send PR to merge to back to develop. Only long term future feature might be created as feature branch in apache/incubator-eagle repository.

...

  1. User for the develop branch to his own repository, say from apache/incubator-eagle/tree/dev => ralphsu/incubator-eagle/tree/devdevelop, then create feature branch hdfs-audit-log or ${JIRA-ID} (which is recommended as it's much easy to track the changes, especially for long-time work)
  2. User continue add code on ralphsu/incubator-eagle/tree/hdfs-audit-log, and suggest continuously pull from apache/incubator-eagle/tree/dev develop to keep sync.
  3. User send PR to develop branch at target release cycle.

E2E Test

If we After setup E2E automation test, it could based on the branch when each branch should test master/all release/hotfixed branches when they have new commit.