OuroDev Git Workflow
The following agreed upon development lifecycle describes the workflow used for working with and delivering code for Volume 2.
All development for features or bugfixes shall be completed in feature branches that are created from the develop branch. Each dev will be responsible for creating and maintaining their feature branch. To be promoted to the develop branch, a feature branch shall submit a Pull Request (PR) to CoX/Source.
The develop branch is the latest "unstable" or in-development codebase. All feature branches are merged into the develop branch using PRs. See the PR submission rules for what is required to merge a PR into the develop branch.
The master branch is the latest "stable" codebase. All releases reside in the master branch. When the develop branch reaches a potential release state, it is merged into master. A tag is then applied to the master branch to mark it as either a release candidate or a final release version.
Sometimes the master branch will have a release candidate (rc) tag applied to it. This is usually when some additional testing needs to be done before declaring a final release version.
Each final release shall be marked in the master branch with a release tag. Most servers should utilize builds from a release tag, as the master branch may sometimes represent release candidates with stable, but incomplete feature implementation. These final release tags are in the form of “v2-i1.0.0”, representing volume 2, issue 1, update 0, patch 0.
PR submission rules
For a PR to be submitted to the develop branch, the following criteria must be verified:
- The PR branch must pull from develop prior to submitting the PR.
- The PR branch must build.
- The PR branch must clearly provide a feature or bugfix and steps to resolve the bug or test the feature.
- The PR must be reviewed and approved by 2 approved reviewers. Currently, approved reviewers are anyone with the Mender or Vindicator role.
- All NEW code must follow the [OuroDev Coding Standards] (to be determined)