Maintainer's guide

Summary

Where to push a bugfix? Where to push a feature? How to start a new feature set? How to publish a release candidate or a release?

The answers are here.

Table of Contents

• Status of branches
• 1.10 is stopped
• 2.10 is on track
• 2.11 is on track
• 3.0 is on track
• 3.1 is in development
• Release cheatsheet
  • Release 3.0.1

Status of branches

Tarantool evolves in several parallel tracks. A developer looks on it as on branches in git. A user sees releases, feature sets and release series.

Git branch	Feature set	Latest (pre)release
release/2.10	2.10	2.10.8
release/2.11	2.11	2.11.2
release/3.0	3.0	3.0.0
master	3.1	not yet

Once we released a particular set of features, we generally shouldn't extend it with new features. It gives the simple rule, what kind of patches should go to what branches:

Git branch	Low-risk bugfixes?	Bugfixes?	New features?	Breaking changes?
release/2.10	Yes	No	No	No
release/2.11	Yes	Yes	No	No
release/3.0	Yes	Yes	No	No
master	Yes	Yes	Yes	No

Qualifying a bugfix as low-risk is in responsibility of CTO and the Product Team.

An exception is possible, but it requires explicit agreement of CTO and the Product Team.

1.10 is stopped

Release 1.10.15 is planned as the last one.

2.10 is on track

We push low-risk bugfixes here after CTO and the Product Team approve.

2.11 is on track

We push bugfixes here.

3.0 is on track

We push bugfixes here.

3.1 is in development

Features and bugfixes go here.

No breaking changes.

Release cheatsheet

Release 3.0.1

• Checkout the latest release/3.0 commit.
• Generate changelogs/3.0.1.md.
• rm changelogs/unreleased/*.md.
• Push annotated tag 3.0.1.
• Release 3.0.1 on GitHub.
• Notify the Infrastructure Team.
• Update the 'Latest release' column in the table in this document.