Skip to content

Finalizing a release

Wouter E edited this page Nov 9, 2020 · 3 revisions

Finalizing a release

This page contains a description of how a new release of the project is formed.

Commiting

The master branch may only contain finalized releases of the project. In order to assure this, we have decided upon the following rules related to committing code to GitHub.

Feature Branches

For every feature that will begin development, a branch with the following naming format has to be created: "sprint-{Sprint Number}-{Feature Name}" These branches can be used to commit to during development of their respective features. See our "Coding standards" for rules to follow when commiting to a feature branch. When the development within a feature branch is complete, a feature branch can be merged into it's sprint branch via a pull requests. These steps are described in the paragraphs below.

Sprint branches

For every sprint that will begin development, a branch with the following naming format has to be created: "sprint-{Sprint Number}" These branches can be used to merge feature branches into once they are ready. When the end date of a sprint is reached, a sprint branch will be merged into the master branch. This merge means the release of a new version of the project. The features that have been merged into the sprint branch during this sprint will have to be noted in the CHANGELOG.md on the master branch within a new version.

Pull Requests

In order to merge a feature branch into a sprint branch, the members developing need to create a pull request. The members can assign other members to peer review there pull request, in order to assure the code is up to standard and the feature works correctly. The members that peer review the request can deny, if they choose to do so they need to explain their reasoning via comments. If the members that peer review decided to accept the request, they can merge the feature branch into the current sprint branch.

Updating the changelog

The changelog will be updated with every new release, which occurs at the end of a sprint. In order to update the changelog, on or multiple members goes through the merges that occured between the feature branches and the sprint branches. For every feature added to the sprint branch, a point can be added to the changelog of the current version. The released are numbered via their sprint number in the following naming format: "[0.{Sprint Number}] - DD-MM-YYYY"

Clone this wiki locally