Release Workflow

Versioning

Versions should follow semantic versioning format. Version tags must always use full format: v<MAJOR>.<MINOR>.<PATCH> (e.g. v2.3.0).

Releases

Development

All new development is done on development branch (dev) by merging GitHub PRs into dev branch. When starting new release cycle, the development branch should be tagged with an alpha version of the next release.

New Release

New releases are releases that increase major or minor number for the version. New releases are prepared on release branches, e.g. release 2.3.0 would be prepared in branch release/2.3.x.

Release process consists of following steps:

1. create new release branch release/<MAJOR>.<MINOR>.x based on dev branch (e.g. release 2.3.0 would have release/2.3.x)
2. update CHANGELOG.md with changes since alpha (e.g. release 2.3.0 would list changes since tag v2.3.0-alpha)
3. create new beta tag representing pre-release version (e.g. v2.3.0-beta)
4. add/cherry-pick only fixes to the release branch
5. when release is ready, switch to master branch and merge the release branch into master
6. create new annotated release tag for the final release version (e.g. v2.3.0, do not omit last zero!)
7. merge the release branch into the dev branch

When the master branch is ready, it is tagged using annotated tag in this format:

• tag name: v2.0.0
• message: Release 2.0.0

Git command:

git tag -m 'Release 2.0.0' v2.0.0`

Then the tag is pushed to the upstream repository (git push --tags upstream). After the tag is pushed to the upstream, new GitHub release is created, using this format:

• release title: Release 2.0.0
• description: See [Release notes](https://github.com/ligato/vpp-agent/blob/master/CHANGELOG.md#v2.0.0)

Patch Release

Patch releases are , new release branch is created (if doesn't exist yet) based on the last release from same minor version. The release branch has name in following format: release/2.0.x.

Then all the necessary fixes are cherry-picked to this release branch, after that the CHANGELOG.md file is updated with relevant information and new tag is created for the respective patch version. After that the release branch can be merged into dev branch (used to sync CHANGELOG).