Skip to content

Release Documentation

Overview

Each new release of OVN-Kubernetes is defined with a "version" that represents the Git tag of a release, such as v1.0.0. This contains the following:

  • Source Code
  • Binaries
    • ovnkube: which is our main single all-in-one binary executable used to launch the ovnkube control plane and data plane pods in a kubernetes deployment
    • ovn-k8s-cni-overlay: is the cni executable to be placed in /opt/cni/bin (or another directory in which kubernetes will look for the plugin) so that it can be invoked for each pod event by kubernetes
    • hybrid-overlay-node
    • ovn-kube-util: contains the Utils for ovn-kubernetes
    • ovndbchecker
    • ovnkube-trace: is the binary that contains ovnkube-trace which is an abstraction used to invoke OVN/OVS packet tracing utils
    • ovnkube-identity: is the executable that is invoked to run ovn-kubernetes identity manager, which includes the admission webhook and the CertificateSigningRequest approver
  • ovnkube API configuration
  • scripts used to deploy OVN-Kubernetes including helm charts
  • Images for fedora and ubuntu

Release Planning

  • OVN-Kubernetes projects uses milestones to track our release planning
  • All PRs and Issues must be tagged with the correct milestone so that it get's included in the release planning
  • Please check our roadmap for more details on our release tracking process

Release Cadence

  • We will do three major releases each year. Ex: 1.x.0 in April 2026 and 1.y.0 in August 2026 and 1.z.0 in December 2026
  • The release timings have been fixed roughly to be 3 or so months after a major Kubernetes release (allowing time for that to stabilize and for us to consume that kube release before we cut our own release)
  • At a given time we will maintain only two active major releases (So when 1.2.0 is released we will stop maintaining and backporting fixes into 1.0.0)
  • For a supported major release we will continue to do backports for backfixes and offer support. A minor patch release will be done at a cadence of 4 weeks for every major release. Ex. Once 1.0.0 is release, we will do 1.0.1, 1.0.2, 1.0.3 etc. This also depends on a case-by-case basis based on demands from end-users and backport statuses.

Release Process

  • You can find our current releases here.
  • Every major release cut will be preceded by an alpha prerelease and beta prerelease.
  • See sample release PR which will become the head commit for a given release.
  • Branch will be cut on the day of release once the release PR merges.
  • CI-CD for the release branch will be added to the GitHub Workflow.

BackPort Request

  • If a PR needs to be backported to an older release that should be requested by adding the needs-backport label.
  • Reach out to the maintainers on slack or by tagging them directly on the PR or come to the community meetings to discuss this.

Information on Past Releases