Mazzocchi Brothers' HandBook

About releases

We create releases to bundle and deliver iterations of a project;
they are based on Git tags, which mark a specific point in the repository’s history.

Creating a release

When the code on develop branch is stable and ready for a new release:

  1. Update CHANGELOG.md and package.json(if any, otherwise go to step 3):
    • In the package.json only the version number changes (see Versioning)
    • the changelog is filled by the list of all PR’s from the latest release till now, grouped by scope (fix, change, new feature)
  2. Push this small update with no business logic directly to develop branch, without any PR (usually with a commit message like: Bump version to v0.0.1). The dev CI/CD pipeline won’t be triggered by this merge.
  3. Make a PR from develop to master branch, naming it as Release <tag name> (Release v0.0.1 for example).
  4. After the PR is merged to master branch, create a git tag locally:
    • Switch to master branch and pull changes
    • Create an annotated tag with git tag -a v0.0.1 -m "Release v0.0.1"
    • Now push the local tag to remote with git push origin v0.0.1
  5. In your local project make sure you have fetched all changes and both develop and master local branches are updated. (see the note below)
  6. From develop branch make git merge master and then git push to realign both branches at the same commit (local and remote). (see the note below)
  7. If manual tests pass and no other bugfix are needed, from GitHub Releases page Create a new release:
    • select the previous created tag
    • put the same tag name as title of the release
    • use Auto generate release notes to generate the release changelog from the list of PR’s
    • Publish the release

Note: points 5 and 6 are needed only if in the repo develop is set as the main branch while master is only the release branch)

At this moment the release (the tag), master and develop point exactly at the same commit in the history

Versioning

We use Semantic Versioning

Given a version number MAJOR.MINOR.PATCH, increment the:

  1. MAJOR version when you make incompatible API changes
  2. MINOR version when you add functionality in a backwards compatible manner
  3. PATCH version when you make backwards compatible bug fixes