Skip to content

Versioning Policy

This document describes the versioning policy that we try to follow in the DBOD service. It is our intention to adjust to it as much as possible.

PostgreSQL

For PostgreSQL, a new major version is published every year, just before mid-November, as can be seen at https://www.postgresql.org/support/versioning/. Each version is supported for 5 years. At least one minor release for all/each supported major release is released every quarter, with all the latest bug and security fixes. Additional minor releases are released, unscheduled, only if necessary, due to security or very serious bugs.

We integrate in DBOD the latest major version only when it has been available for at least one year (after 5/6 minor releases) to avoid instability and mitigate the risks of early adoption. We remove the oldest version just before/after it becomes unsupported. So a major version should be available up to 4 years at max. Because of this, in the longer term, we will have to support up to 3-4 major versions at the same time. We integrate and ask to apply the latest minors once per year, instead of every quarter.

In this scenario, if an instance is ALWAYS on the oldest supported major version, it will need to go through a major upgrade every year, but if a user upgrades to the latest major version available (instead of the next major), he/she will not be forced to do another major upgrade for a few years (up to 3/4), until the latest version is, in turn, deprecated. For PG, the general advice is to go with the latest version you can afford to be, because of the benefits in terms of performance improvements, security and bug fixes, even when new features are not tremendously interesting.

In summary, we force a minor upgrade, which normally consist in the restart of the instance, once per year (or, exceptionally, when required for security or serious bugs). Minor upgrades normally do not require changes in the application. Once per year, we have also to deprecate unsupported versions. Next time this will happen (for PG 13) around November 13th, 2025. Whenever possible, we plan to make this occurring in the same period, so that our users are able to major upgrade to the latest version, without requiring the upgrade to a new minor version, until one year is passed.

MySQL

For MYSQL the situation is a bit different. A very good source of information is https://blogs.oracle.com/mysql/post/introducing-mysql-innovation-and-longterm-support-lts-versions.

As can be read there:

  • The patch releases of MySQL 5.7 and previous releases were focused on bugfix and security patches. That changed in MySQL 8.0 with the continuous delivery model in that patch releases also contained new features.

  • We understand that this approach can cause challenges for projects and applications that require only critical patches with less frequent behavior changes. We listened to your feedback and observed industry trends, and we are now transitioning to a versioning model where you can choose between Innovation and Long-Term Support (LTS) releases.

Due to resource constraints, we have decided to integrate and support in DBOD only LTS versions which should be published every 2 years, and have 5 years of premier and 3 years of extended support. As it occurs for Oracle, new minor releases are published every quarter (but our colleagues in IT-DA-DB are applying the patches only twice per year). They can have a stronger impact and requiring changes in the application (or in the administration). Major upgrades are even more challenging but because major version can last 5+3 years, they would normally occur much less frequently.

In summary, while we are adopting the new LTS path, we plan to request a mandatory minor upgrade once per year (or, exceptionally, when required for security or serious bugs) and major upgrades whenever an LTS is becoming deprecated but at this stage is not clear how many LTS versions we will support concurrently. Looking at the past, while considering the new versioning policy, it will probably be at least two but difficult to go beyond three. This also taking into account that we might integrate a new LTS after one year of the publishing date.