Release Management

Occasionally, the OpenVMM project will declare upcoming release milestones. We stabilize the code base in a release/YYMM branch, typically named for the YYMM when the branch was forked. We expect a high quality bar for all code that goes in to the OpenVMM main branch, we ask developers to hold these release/YYMM to the highest quality standards. The OpenVMM maintainers will gradually slow the rate of churn into these branches as we get closer to a close date.

This process should not impact your typical workflow; all new work should go into the main branch. But, to ease the cherry-picks, we may ask that you hold off from making breaking or large refactoring changes at points in this process.

Marking, Approval Process, Code Flow

The OpenVMM maintainers will publish various dates for the upcoming releases. Currently, these dates are driven by a Microsoft-internal process and can, and do, often change. Microsoft does not mean to convey any new product launches by choices of these dates.

Releases naturally fall into several phases:

PhaseMeaning
Active DevelopmentRegular development phase where new features and fixes are added.
StabilizationPhase focused on stabilizing the release by fixing bugs.
Ask ModeChanges are scrutinized and only critical fixes are allowed. No new features are accepted. This is the last phase before a release is closed.
ServicingOnly essential fixes are made to support the release. a.k.a. maintenance mode

release/2411 process

We track the state of candidates for a given release by tagging the PRs:

  • backport_YYMM: This PR (to main) is a candidate to be included in the YYMM release.
    • N.B.: A maintainer will remove this tag if the fix is not accepted into the release.
  • backported_YYMM: This PR (to main) has been cherry-picked to the YYMM release.
  • backport_YYMM_approved: This PR (to main) has been reviewed by the OpenVMM maintainers, who believe this meets the bar. This is a temporary tag until the PR is cherry-picked (e.g. a TODO).

Seeking Approval for Backport

To seek approval to include a change in a release branch, follow these steps:

  • Tag your to-main PR with backport_YYMM.
  • Cherry-pick the change to the appropriate release/YYMM branch in your fork and stage a PR to that same branch in the main repository.

Please reach out to the maintainers before staging that PR if you have any doubts.

Existing Release Branches

ReleasePhaseNotes
release/2411Ask Mode

Depending on Releases

We welcome feedback, especially if you would like to depend on a reliable release process. Please reach out!