Skip to content
mdavidsaver edited this page Jun 2, 2015 · 8 revisions

Developer workflow (aka. branching policy)

The main/official repositories under the epics-base github group are used for releases. Development is done outside of the official repositories.

It is suggested to use the github fork process to create a personal repository to hold work in progress. Either as a prelude to creating a pull request, or to work with others as collaborators.

A developer may allow other github users to push changes to a personal repository by adding them as collaborators for that repository.

Branch and Tag names

In the main/official repository the focus of active development is the "default" branch. Releases are marked by tags with the release number separated by dots (ie "4.0.1"). Bugfix/patch releases are made on branches named for the series ("release/"). For example, "release/4.0" would contain bugfixes in the 4.0.X series.

Release branches need not be created until the first bugfix is committed.

Review policy

Minor changes by developers with permission may be pushed directly to the main repositories. Significant or contentious changes (ie. API breaks) should be posted for review prior to being included in the main repositories. Review through github a pull requests in the preferred mechanism.

See the project wide list of open pull requests.

The threshold to trigger "formal" review is at the discretion of developers. Consideration should be given to the effects of the change. Changes which are significantly disruptive (ie. API breaks), or which carry a higher risk of bugs, are good candidates for review.

Issues

See the project wide list of open issues.

Clone this wiki locally