Skip to content

Latest commit

 

History

History
65 lines (49 loc) · 3.44 KB

release-process.md

File metadata and controls

65 lines (49 loc) · 3.44 KB

Release Process

This document outlines the release process for NGINX Kubernetes Gateway (NKG).

Versioning

NKG uses semantic versioning for its releases. For more information, see https://semver.org.

Major version zero (0.Y.Z) is reserved for development, anything MAY change at any time. The public API is not stable.

Release Planning and Development

The features that will go into the next release are reflected in the corresponding milestone. Refer to the Issue Lifecycle document for information on issues creation and assignment to releases.

Releasing

Note: in the instructions below, X stands for the major version, Y -- minor, Z -- patch.

Major or Minor Release

A Major or minor introduces new features.

To create a new release, follow these steps:

  1. Create an issue to define and track release-related activities. Choose a title that follows the format Release X.Y.Z.
  2. Stop merging any new work into the main branch.
  3. Test the main branch for release-readiness. For that, use the edge containers, which are built from the main branch.
  4. If a problem is found, prepare a fix PR, merge it into the main branch and return to the previous step.
  5. Create a release branch with a name that follows the release-X.Y format.
  6. Prepare and merge a PR into the release branch to update the repo files for the release:
    1. Update the tag of NKG container images used in the installation manifests and docs to X.Y.Z.
    2. Ensure that the imagePullPolicy is IfNotPresent in the installation manifests.
    3. Modify any git clone instructions to use vX.Y.Z tag.
    4. Adjust the VERSION variable in the Makefile to X.Y.Z.
    5. Update the README to include information about the release.
    6. Update the changelog. The changelog includes only important (from the user perspective) changes to NKG. This is in contrast with the autogenerated full changelog, which is created in the next step. Use the previous changelog entries for formatting and content guidance.
  7. Create and push the release tag in the format vX.Y.Z. As a result, the CI/CD pipeline will:
    • Build NKG container images with the release tag X.Y.Z and push it to the registry.
    • Create a GitHub release with an autogenerated changelog and attached release artifacts.
  8. Prepare and merge a PR into the main branch to update the README to include the information about the latest release and also the changelog.
  9. Close the issue created in Step 1.

Patch Release

A patch release is for an important fix that cannot wait the next major/minor release.

To create a new release, follow these steps:

  1. Create an issue to define and track release-related activities. Choose a title that follows the format Release X.Y.Z.
  2. If the fix applies to both the latest release and the main branch, then:
    1. Prepare and merge a fix PR into the in the main branch.
    2. Prepare and merge a fix PR (with a cherry-pick commit) into the existing release branch.
  3. Alternatively, if the fix only applies to the latest release, prepare and merge a fix PR into the existing release branch.
  4. Test the release branch for release-readiness.
  5. If a problem is found, return to Step 2.
  6. Follow Steps 6-9 from the Major or Minor Release section.