# OVN Release Process

This document describes the process ordinarily used for OVN development and release. Exceptions are sometimes necessary, so all of the statements here should be taken as subject to change through rough consensus of OVN contributors, obtained through public discussion on, e.g., ovs-dev or the #openvswitch IRC channel.

## Release Strategy

OVN feature development takes place on the “main” branch. Ordinarily, new features are rebased against main and applied directly. For features that take significant development, sometimes it is more appropriate to merge a separate branch into main; please discuss this on ovs-dev in advance.

The process of making a release has the following stages. See Release Scheduling for the timing of each stage:

1. “Soft freeze” of the main branch.

   During the freeze, we ask committers to refrain from applying patches that add new features unless those patches were already posted for public review and had received public review feedback on the mailing list before the freeze began. Bug fixes are welcome at any time. Please propose and discuss exceptions on ovs-dev.

2. Fork a release branch from main, named for the expected release number, e.g. “branch-25.09” for the branch that will yield OVN 25.09.x.

   Release branches are intended for testing and stabilization. At this stage and in later stages, they should receive only bug fixes, not new features. Bug fixes applied to release branches should be backports of corresponding bug fixes to the main branch, except for bugs present only on release branches (which are rare in practice).

   At this stage, sometimes there can be exceptions to the rule that a release branch receives only bug fixes. Like bug fixes, new features on release branches should be backports of the corresponding commits on the main branch. Features to be added to release branches should be limited in scope and risk and discussed on ovs-dev before creating the branch.

   In order to keep the CI stable on the new release branch, the Ubuntu container should be pinned to the current LTS version in the Dockerfile e.g. registry.hub.docker.com/library/ubuntu:22.04.

3. When committers come to rough consensus that the release is ready, they release the .0 release on its branch, e.g. 25.09.0 for branch-25.09. To make the actual release, a committer pushes a signed tag named, e.g. v25.09.0, to the OVN repository, makes a release tarball available on openvswitch.org, and posts a release announcement to ovs-announce.

4. As bug fixes accumulate, or after important bugs or vulnerabilities are fixed, committers may make additional releases from a branch: 25.09.1, 25.09.2, and so on. The process is the same for these additional release as for a .0 release.

## Long-term Support Branches

The OVN project will periodically designate a release branch as “long-term support” or LTS for short. An LTS branch has the distinction of being maintained for longer than a standard branch.

LTS branches will receive bug fixes and have releases made regularly until the point that another LTS is released. At that point, the old LTS will receive an additional year of critical and security fixes. Critical fixes are those that are required to ensure basic operation (e.g. memory leak fixes, crash fixes). Security fixes are those that address concerns about exploitable flaws in OVN and that have a corresponding CVE report. Whenever such a fix is applied, a new release will be made for the LTS version.

LTS branches are scheduled to be created once every two years. This means that any given LTS will receive bug fix support for two years, followed by one year of critical bug fixes and security fixes.

The current LTS version is documented on the Long Term Support Releases page of ovn.org.

## Standard-term Support Versions

Versions of OVN that are not designated as LTS versions are standard-term support releases.

Standard term support versions will have releases made regularly for one year. There are no additional windows for which releases will be made for critical or security fixes.

The branches for standard term support versions may receive bug fixes and critical and security fixes after the OVN team has stopped creating regular releases. This is to facilitate easy backporting of fixes to LTS versions that are still receiving regular releases. Even though the branch may receive additional fixes, no releases will be made with these fixes.

Sometimes, a fix can be backported to these branches if requested by the user or author of that fix. The request maybe rejected by the maintainers if it is deemed risky or complex.

## Release Numbering

The version number on main should normally end in .90. This indicates that the OVN version is “almost” the next version to branch.

Forking main into branch-x.y requires two commits to main. The first is titled “Prepare for x.y.0” and increments the version number to x.y. This is the initial commit on branch-x.y. The second is titled “Prepare for post-x.y.0 (x.y.90)” and increments the version number to x.y.90.

The version number on a release branch is x.y.z, where x is the current year, y is the month of the release, and z is initially 0. Making a release requires two commits. The first is titled Set release dates for x.y.z. and updates NEWS and debian/changelog to specify the release date of the new release. This commit is the one made into a tarball and tagged. The second is titled Prepare for x.y.(z+1). and increments the version number and adds a blank item to NEWS with an unspecified date.

## Release Scheduling

OVN makes releases at the following six-month cadence. All dates are approximate:

Time (months) | Example Dates | Stage
T | Mar 15, Sep 16, … | Begin x.y release cycle
T + 4 | Jul 15, Jan 15, … | “Soft freeze” main for x.y release
T + 5 | Aug 15, Feb 15, … | Fork branch-x.y from main
T + 6 | Sep 15, Mar 15, … | Release version x.y.0

### Subsequent Releases

Beyond the .0 release of an OVN version, we will schedule further regular releases from its development branch. The most recent release branch, as well as the current LTS branch, will receive new releases every two months. If the most recent release branch is an LTS branch, then that branch alone will have releases made every two months. Other standard-term support branches that are still under support will receive new releases every three months. If for some reason, no changes occur to a supported OVN branch during a release period, then no release will be made on that branch for that period. Therefore, there is no guarantee about the exact number of releases to be expected for any given OVN version.

## Release Calendar

The 2026 timetable is shown below. Note that these dates are not set in stone. If extenuating circumstances arise, a release may be delayed from its target date.

Release | Soft Freeze | Branch Creation | Release
26.03.0 | Jan 23 | Feb 20 | Mar 20
26.09.0 | Jul 24 | Aug 21 | Sep 18

Below is the 2027 timetable. Note that unlike in previous years, this calendar proposes Tuesday releases instead of Friday releases. However, soft freeze and branching dates are still on Fridays.

Release | Soft Freeze | Branch Creation | Release
27.03.0 | Jan 22 | Feb 19 | Mar 23
27.09.0 | Jul 23 | Aug 20 | Sep 21

## Contact

Use dev@openvswitch.org to discuss the OVN development and release process.