Core Team Development Processes

Feature development / bug fixing

1. Developer performs feature work or bug fix on a branch off of master.
2. Developer opens a pull request against master once the work is completed. The PR should include a change to CHANGELOG.md summarizing the work.
3. Reviewer reviews the PR and either requests changes or approves.
4. After approval, the reviewer squashes and merges to master, updating the commit message to provide a message that summarizes the entirety of the work item. This aggregate commit message must be prefixed with either [BUG FIX] #123 or [FEATURE] #123 where 123 is the Issue number.

Release

1. Developer opens a PR against master to update the version in mix.exs and to update the release date within CHANGELOG.md.
2. PR lands to master with a commit message of [RELEASE] x.y.z with the appropriate version number.
3. A Github Release is created with the Tag version and Release title formatted as vx.y.z (e.g. v1.0.0) and the corresponding list of Enhancements and Features as well as any other relevant information for the release copied from CHANGELOG.md into the description.
4. A PR is opened to merge master to test, after it builds and merged any required testing is done on tokamak.oli.cmu.edu
5. A PR is opened to merge master to prod. After it builds it is merged to trigger the deployment to production.

Examples

The following is an example of what the above guidelines yield in the commit history on master:

[RELEASE] v0.4.1
[BUG FIX] #123 Restored ability to sort media items by size
[BUG FIX] #124 Corrected position of image thumbnails within media library
[FEATURE] #125 Added new Ordering activity type