How to release

How to release

• Make sure tests passed in master branch.

• Make sure changelog contains a section for Unreleased version and section contains all user-visible breaking changes, new features and bugfixes, link related issues. But refrain yourself from being too formal.

• Prepare a pull request with updated CHANGELOG. Rename 'Unreleased' version to the next version number with release date and add a new empty section 'Unreleased' with empty Added, Changed, Fixed subsections. Every release has a semantic version. A semantic version has the form vMAJOR.MINOR.PATCH. Given a version number MAJOR.MINOR.PATCH, increment the:

  • MAJOR version when you make incompatible API changes,
  • MINOR version when you add functionality in a backwards-compatible manner, and
  • PATCH version when you make backwards-compatible bug fixes.

In general, we follow a versioning policy recommended by Golang authors. You can specify pre-release versions by appending a hyphen and dot separated identifiers (for example, v1.0.1-alpha or v2.2.2-beta.2). Normal releases are preferred by the go command over pre-release versions, so users must ask for pre-release versions explicitly (for example, go get example.com/[email protected]) if your module has any normal releases.

It’s important to keep tagging new releases as you develop your module. When users request a new version of your module (with go get -u or go get github.com/tarantool/go-tarantool), the go command will choose the greatest semantic release version available, even if that version is several years old and many changes behind the primary branch. Continuing to tag new releases will make your ongoing improvements available to your users.

• Prepare the new release draft with release notes. Usually, release notes contain a short description and a list of changes copy-pasted from changelog. Below is a template for new release notes:

## Overview

A description of the release.

## Breaking changes

Warn a user about breaking changes here.

## New features

* Short description (#xx).

## Bugfixes

* Short description (#xx).

## Testing

* Short description (#xx).

## Other

* Short description (#xx).

See release notes in v1.6.0 and in tarantool-python as examples. Set 'Release title' to a new release version number, and set 'This is a pre-release' checkbox. Feel free to share release notes draft with teammates to get valuable feedback.

• Get an LGTM for a pull request with updated changelog and merge it to a master branch.
• Pull master branch and create annotated tag with release version number: git tag -a --cleanup=verbatim vX.Y.Z (why vX.Y.Z). Annotate is used for convenience and is usually containing release notes. Push changes: git push origin vX.Y.Z. Or, in case of any error, remove them and proceed again: git tag -d vX.Y.Z. It is okay to remove a Git tag right after pushing, but do not delete version tags from your repo after some time. If you find a bug or a security issue with a version, release a new version. In short: "Фарш невозможно провернуть назад". If people depend on a version that you have deleted, their builds may fail.
• You can run go list -m github.com/tarantool/[email protected] to confirm the latest version is available. If you don’t see the latest version immediately, and you’re using the Go module proxy (the default since Go 1.13), try again in a few minutes to give the proxy time to load the new version.
• Set a proper Git tag in release draft, remove 'This is pre-release' and publish release.
• Send request for announcing to the Tarantool's marketing team.