Release Planning

The Xen Project follows a regular release schedule. This page describes how releases are planned and what the development cycle looks like.

Release schedule

Xen Project targets three major releases per two years, releasing approximately every 8 months. Dates are chosen to avoid major holidays; if one release slips, the following cycle is typically shortened to compensate rather than shifting the whole schedule. Feature freeze and release candidate dates for the current cycle are announced on xen-devel — see Release Management for the roles involved and the process the Release Manager follows.

Development cycle

Each release cycle is roughly six months of development followed by a freeze of about two months:

• Development window (~6 months): New features and significant changes are merged.

• Feature freeze: Only bug fixes and documentation improvements are accepted after the cut-off date. The freeze can run shorter or longer than two months; if it runs long, it shortens the next development window.

• Release candidate: The release is stabilized, with RC builds published for community testing.

• Release: The final release is tagged and announced.

Long-term support

Xen Project releases are supported for at least five years after their initial release. Security fixes are backported for an extended period. See the support matrix for current support status of each release.

Getting involved in releases

You can help with release quality by testing release candidates and contributing fixes for known issues before the feature freeze.

Testing release candidates

RC announcements go to xen-devel. What’s most useful to test varies with what you actually run: host hardware (Intel vs AMD, NUMA topology), dom0 distribution and kernel, guest OS, and virtualization mode all affect whether something works - a guest that fails on one combination may work fine on another, so include these details in any report.

A few commands cover the basics before you dig into anything specific:

xl list          # confirm domains are running
xl info          # hypervisor version and resources
xl dmesg         # hypervisor boot log
xenstore-ls      # XenStore contents
dmesg | grep -i xen   # kernel recognizes it's running under Xen

Beyond that, testing the workflow you actually rely on — creating and destroying guests, attaching devices, migrating, or whatever’s part of your normal usage — surfaces real regressions more reliably than working through an arbitrary checklist. Report results, positive or negative, to xen-devel.