Introduction

This is a forever draft document about the general steps of releasing Tryton.

Here we will never stop to collect the wisdom of our experiences from release to release.

This knowledge should be more a list like collection of facts, than a continuous text about possibilities.

The Tryton Release process is inspired by the OpenBSD Release Process. To get a conception of the process please have a look at a video of The OpenBSD Release Process at AsiaBSDCon 2009

Parts of the Tryton project to release

• Every part of Tryton, the user needs to install and run the complete application.
• Development and build-for-release specific parts are not released, they are always current in the development tree.
• The Tryton server/client application will be released separately from the modules.

tryton/trytond: server/client application

• The server and the client are released:
• at the same time;
• under the same version number;
• in separate packages;
• on pypi;

modules general

• Each module is released:
• time independent;
• as a separate package;
• on pypi;

Version number of Tryton releases

The Tryton version number is made of thee parts like the following example:

Tryton Version 2.3.5

The first and second number are major version numbers. These general version numbers ...

• ... are used to indicate a major step in the evolution of Tryton;
• ... are published twice per year;
• ... can change parts of the database structure;
• ... could need manual steps for database upgrade;

The second number indicates release and development state:

• even number and null: Release version
• odd number: Development version

The third number is the minor version number of Tryton. Releases changing this number...

• ... are published for fix bugs;
• ... don't change the database structure;
• ... don't need a database upgrade;
• ... are considered as unproblematic for update;

Major release process

We make a major release every 6 months:

• The client/server development is frozen about 2 months before the date.
• Leaders check their modules (and documentation) and freeze development about 1 month before the date. If a leader fails, a new leader is chosen.
• Translation teams check the translation.
• Community testing until release.

Tagging of Tryton releases in DSCM

• the default branch is copied to a release branch at the release date;
• "freezing" of the default branch before releasing is handled by maintainers discipline;