Release process


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. The next release date is chosen after a release and published at Tryton’s events calendar.

What is released?

  • 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.


Minor Releases are maintained for at least 1 year.
Long Term Release are maintained for at least 5 years.
Maintenance means there will be bug-fix releases during the period.

Here is an example of the timeline:

* 5.0 10/2018 --> 10/2023    |---.---.---.---.---|
* 5.2  5/2019 -->  5/2020      |---|
* 5.4 10/2019 --> 10/2020        |---|
* 5.6  5/2020 -->  5/2021          |---|
* 5.8 10/2020 --> 10/2021            |---|
* 6.0  5/2021 -->  5/2026              |---.---.---.---.---|
* 6.2 10/2021 --> 10/2022                |---|

Version number of Tryton releases

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

Tryton Version 2.3.5

Major release

The first and second number are series 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;

Long Term Release are release with series ending by 0.

Minor release

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

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


The migration between series is managed by updating the database. Some release may require manual operation which are published under migration category.
The process is supported from one series to the direct following and from one LTS to the direct next one (by applying operations of each series in between).

Development state

The second number indicates development state:

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

Major release preparation

The development is frozen about 1 month before the scheduled date.
“freezing” is handled by maintainers discipline.

During freezing:

  • Translation teams update the translation of each repositories.
  • Everybody test and report issues until release.
  • The reviews related to new features are not reviewed and not applied.

Release process

We use the scripts from from within the repository to release.

It just requires to have the environment variable TRYTON_GPG_KEY.

Major release

Execute the following command:

$ do_major_release

Minor release

Execute the following command:

$ do_minor_release

We have now a script tryton-tools: c6d07120dd7b that update the translations every month. So I propose to reduce the freezing to 2 weeks as translators can fill the translations for new modules every months during the 6 months of development.

That makes sense! I also think that having 2 weeks to translate all the strings is enough, even if no translations is done on the development period.

Prior to the existance of LTS releases (versions older that 5.0) where supported for 2.5 years.
So I’m wondering if versions 4.2, 4.4 and 4.6 are still supported as they are older than one year but they where supported by the previous release process.

For me, the contract changed after the release so we should stick with what was announced at the release time.

I like your proposal a lot. Will you use a cron job or a fixed date like every first day of a month? So the translators can schedule their time.

It is already in place and it is the first day of each month.

There are nothing to schedule as there are any planning to add or modify terms.

Misunderstanding. I just meant it is good for the personal schedule and for the collaboration of the translators to have a periodical recurring date for the translation updates. As you said, it is the case.