diff --git a/release_process.md b/release_process.md index 2a8d82963f..6ac277c30e 100644 --- a/release_process.md +++ b/release_process.md @@ -1,71 +1,90 @@ # Release Process -This document outlines the release process for Ignite. It ensures consistency, quality, and clear communication with users. -Ignite uses [semantic versioning](https://semver.org/) to indicate the stability and compatibility of releases. +This document outlines the release process for Ignite, ensuring consistency, quality, and clear communication with users. Ignite follows [semantic versioning](https://semver.org/) to signal the stability and compatibility of each release. -## Release Branches +## Development Branch -Releases are tagged from release branches. The release branch is typically named after the release version, such as `release/v28.x.y` or `release/v30.x.y`. The release branch is created from the `main` branch and contains all the changes that will be included in the release. +The `main` branch serves as the development branch for Ignite. All new features, bug fixes, and updates are merged into this branch. The `main` branch is typically updated regularly, depending on development activity. -## Development Branch +## Backporting Features & Bug Fixes -The `main` branch is the development branch for Ignite. All new features and bug fixes are developed on this branch. The `main` branch is typically updated daily or weekly, depending on the amount of development activity. +Features and bug fixes ready for release are backported from `main` to the release branch. This process is automated using [Mergify](https://mergify.com/), a CI/CD tool. By adding the `backport release/x.y.z` label to a PR, Mergify will automatically backport the PR to the release branch when it is merged into `main`. -## Backporting Features and Bug Fixes +## Changelog -Features or bug fixes that are ready to be included in a release must be backported from the `main` branch to the release branch. This is done using Mergify, a CI/CD tool that automates the process of backporting changes. Add the `backport release/x.y.z` label to a pull request (PR) to indicate that it should be backported to the release branch. Mergify will automatically backport the PR when it is merged into the `main` branch. +Before any release, the changelog must be up-to-date. It lists all changes made to Ignite since the last release and must be carefully reviewed to ensure accuracy. -## All PRs Target Main +## Release Cadence: Alpha → Beta → RC → Full Release -All PRs should target the `main` branch. This ensures that changes are always integrated into the development branch and are ready for backporting. +To accommodate Ignite’s dependency on the [Cosmos SDK](https://github.com/cosmos/cosmos-sdk) and the addition of new features, a structured release cadence is used that includes Alpha, Beta, and Release Candidate (RC) stages before the Full Release. This ensures features are thoroughly tested, dependencies are compatible, and disruptions are minimized. -## Changelog +### Major & Minor Releases -The changelog lists all of the changes that have been made to Ignite since the last release. The changelog must be up-to-date before a release is made. +For **major** releases, the Alpha → Beta → RC progression is **required**. For **minor** releases, these stages are **optional** and used at the discretion of recent updates and their complexity. -## Release Preparation and Testing +These stages help ensure stability, especially given Ignite's integration with the Cosmos SDK and potential for breaking changes. This process allows developers to prepare for compatibility changes: -Before a release is made, it is important to prepare the release branches and perform thorough testing. -The process differs depending on whether the release is a `MAJOR`, `MINOR`, or `PATCH` release. +- **Alpha Releases**: Early, incomplete versions with new features that may be unstable, shared internally or with select testers. +- **Beta Releases**: Feature-complete versions shared with the community for feedback and testing. These releases are more stable than Alpha but may still contain bugs. +- **RC (Release Candidate)**: A near-final version with all intended features and fixes. Multiple RCs may be issued for **MAJOR releases** (e.g., `v30.0.0-rc1`, `v30.0.0-rc2`, etc.) as issues are identified and resolved. The final RC becomes the Full Release if no critical issues remain. -### Major Release +### Patch Releases -* Freeze the `main` branch. -* Create a release branch from the `main` branch. - * Update `.github/mergify.yml` to allow backporting changes to the release branch. - * Possibly update CI/CD configuration to support the new release. -* Running all unit tests, integration tests, and manual scenarios. -* Ensuring that the release branch is still compatible with all supported environments. -* Prepare the changelog. +**Patch releases** do not go through Alpha, Beta, and RC stages. They are fast-tracked for release after internal testing, as they address specific bug fixes or security vulnerabilities. Patch releases should remain backward-compatible and thoroughly tested for regressions. + +## Managing SDK Dependencies & Compatibility + +Given Ignite’s reliance on the Cosmos SDK, ensuring compatibility between Ignite releases and the SDK is crucial. When upgrading the SDK version, a transition period may be needed to allow users time to adapt. + +- **Backward Compatibility**: Ignite strives to maintain backward compatibility for `chain` and `app` commands between major releases. This allows users to upgrade Ignite without immediate refactoring. +- **Breaking Changes**: If breaking changes are introduced (such as SDK upgrades or major feature revisions), transition periods will be defined and communicated in release notes starting from Alpha versions. +- **Transition Periods**: When significant changes impact downstream applications, transition periods give users time to test and adapt their applications before the final release. + +## Release Branches -### Minor and Patch Releases +Releases are tagged from dedicated release branches, named after the release version (e.g., `release/v28.x.y` or `release/v30.x.y`). These branches are created from `main` and contain all changes intended for the release. -* Verifying that all wanted changes have been backported to the release branch. -* Running all unit tests, integration tests, and manual scenarios. -* Ensuring that the release branch is still compatible with all supported environments. -* Prepare the changelog. +- **Alpha, Beta, and RC Branches**: Pre-release branches are named accordingly, such as `release/v28.x.y-alpha`, `release/v28.x.y-beta`, or `release/v28.x.y-rc1`, `release/v28.x.y-rc2`, etc. + +## Release Preparation & Testing + +The preparation and testing phases vary depending on the type of release: + +### Major Releases + +- **Freeze `main`**: No new features are merged into `main` during final preparation. +- **Create the release branch**: A new branch (e.g., `release/v30.x.y`) is created from `main`. +- **Backport**: Ensure that all desired features and fixes are backported to the release branch. +- **Testing**: Run unit, integration, and manual tests. +- **Changelog**: Finalize the changelog. + +### Minor & Patch Releases + +- **Backport**: Ensure that all necessary changes are backported to the release branch. +- **Testing**: Conduct unit, integration, and manual tests. +- **Changelog**: Finalize the changelog. ## Release Publication -Once the release is ready, it can be published to the [releases page](https://github.com/ignite/cli/releases) on GitHub. This involves tagging the release branch with the release version and creating a release announcement. The release anouncement should contain the changelog of the release. +When testing is complete, the release is published to the [releases page](https://github.com/ignite/cli/releases) on GitHub. This includes tagging the release branch with the version number and publishing a release announcement with the changelog. -```bash +```sh git checkout release/v28.x.y git tag v28.x.y -m "Release Ignite v28.x.y" ``` -## Post-Release Activities +For Alpha, Beta, and RC releases, use the appropriate tags (e.g., `v28.x.y-alpha`, `v28.x.y-beta`, `v28.x.y-rc1`, etc.). -After a release has been made, it is important to monitor feedback and bug reports to inform subsequent releases. +## Post-Release Activities -This includes updating the `main` branch changelog with the new release. +After a release, monitor feedback and bug reports. These will inform subsequent patch releases or feature additions. -In case of a new `MAJOR` release, the release author must also update the `main` branch to the next `MAJOR` version number: rename the `go.mod` and all references to the version number in the codebase. +Following a **MAJOR** release, the `main` branch must be updated to the next **MAJOR** version. This includes updating the `go.mod` file and any other version number references in the codebase. ## Maintenance Policy -Only the latest released version of Ignite is maintained for new features and bug fixes. Older versions may continue to function, but they will not receive any updates. This ensures that Ignite remains stable and reliable for all users. +Only the latest released version of Ignite is actively maintained for new features and fixes. Older versions may continue to function but will not receive updates, ensuring stability and security for users. + +Users are encouraged to upgrade to the latest release to benefit from the newest features and fixes. -Users are encouraged to upgrade to the latest release as soon as possible to benefit from the latest features and security updates. -Ignite ensures compatibility for the `chain` and `app` commands between major releases. -Other commands may change between major releases and may require the user to upgrade their codebase to the Cosmos SDK version Ignite is using. +Ignite ensures compatibility for `chain` and `app` commands between **MAJOR** releases, but other commands may change and may require users to upgrade their codebase to match the Cosmos SDK version used by Ignite.