# Our Release Process

Bevy uses three-months-long development cycles, delimited by a weeks-long rolling release process.

This means that bevy releases a new version roughly once every three to four months. In an effort to avoid crunch and encourage sustainable development, we do not pick specific dates or deadlines.

## Development Cycles

During a three-month development cycle, maintainers collect important PRs and issues into a github Milestone. Issues included in the milestone are given priority, and the community generally makes a best-effort attempt to merge as many of these as possible over the duration of the cycle.

In the lead-up to a release, generally about about two and a half months after the previous, we begin to aggressively purge the milestone of things that seem unlikely to be ready in time. The main things that tend to remain are:
+ Quick and easy features under active development.
+ Fixes for important regressions or crashes.
+ Large or impressive features that only need minor polish.

When the milestone is complete, we publish a release candidate (ex. `0.14.0-rc.1`) and begin the release process.

## Release Candidates

In the run-up to a release, Bevy publishes a new release candidate about once a week. Publishing release candidates allows users to identify bugs and regressions, gives ecosystem crates time to update so they can be ready closer to release day, and provides bevy contributors extra time to write release notes and migration guides.

When publishing a release candidate, we also announce a general target release date. This is generally about one week out. If critical bugs or regressions are discovered during this testing window, we fix them and publish a new release candidate. Then we either
+ Announce a new date, if we believe more testing time is needed than the current window.
+ Or keep the same target release date if we believe there is enough time in the current window.

When we successfully hit a release candidate's target date, we do the final release.

## Release Checklist

When making a release, the maintainers follow these checklists:

### Minor Version

#### Minor Pre-release

1. Check regressions tag.
2. Check appropriate milestone, and close it.
3. Check GitHub Projects page for staleness.
4. Update change log.
5. Create migration guide.
6. Write blog post.
7. Update book.
8. Bump version number for all crates, using the "Release" workflow.
* Change the commit message to be nicer
9. Create tag on GitHub.
10. Edit Github Release. Add links to the `Release announcement` and `Migration Guide`.
11. Bump `latest` tag to most recent release.
12. Run this workflow to update screenshots:
* <https://github.com/bevyengine/bevy-website/actions/workflows/update-screenshots.yml>
* _This will block blog post releases (and take ~40 minutes) so do it early_.
13. Run this workflow to update wasm examples:
* <https://github.com/bevyengine/bevy-website/actions/workflows/build-wasm-examples.yml>

#### Minor Release

1. Release on crates.io
* `bash tools/publish.sh`
2. Announce on:
1. HackerNews
2. Twitter
3. Reddit: /r/bevy, /r/rust, /r/rust_gamedev
4. Discord: Bevy, Game Development in Rust, Rust Programming Language Community
5. This Month in Rust Game Development newsletter
6. This Week in Rust newsletter

#### Minor Post-release

1. Bump version number for all crates to next versions, as `0.X-dev`, using the "Post-release version bump" workflow, to ensure properly displayed version for [Dev Docs](https://dev-docs.bevyengine.org/bevy/index.html).
2. Update Bevy version used for Bevy book code validation to latest release.

### Patch

#### Patch Pre-release

1. Check appropriate milestone.
2. Close the milestone, open the next one if anything remains and transfer them.
3. Bump version number for all crates, using the command from the "Release" workflow locally, with `patch` for the new version. At the time of writing this:
* `cargo release patch --workspace --no-publish --execute --no-tag --no-confirm --no-push --dependent-version upgrade --exclude ci --exclude errors --exclude bevy_mobile_example --exclude build-wasm-example`
* Change the commit message to be nicer
4. Create tag on GitHub.
5. Edit Github Release. Add link to the comparison between this patch and the previous version.
6. Bump `latest` tag to most recent release.
7. Run this workflow to update screenshots:
* <https://github.com/bevyengine/bevy-website/actions/workflows/update-screenshots.yml>
8. Run this workflow to update wasm examples:
* <https://github.com/bevyengine/bevy-website/actions/workflows/build-wasm-examples.yml>

#### Patch Release

1. Release on crates.io
* `bash tools/publish.sh`
2. Announce on:
1. Discord: Bevy

#### Patch Post-Release

### Release Candidate

#### RC Pre-Release

1. Check appropriate milestone.
2. Create a branch for the release.
3. Bump version number for all crates, using the command from the "Release" workflow locally, with `rc` for the new version. At the time of writing this:
* `cargo release rc --workspace --no-publish --execute --no-tag --no-confirm --no-push --dependent-version upgrade --exclude ci --exclude errors --exclude bevy_mobile_example --exclude build-wasm-example`
* Change the commit message to be nicer
4. Create tag on GitHub.
5. Edit Github Release. Add link to the comparison between this rc and the previous version.

#### RC Release

1. Release on crates.io
* `bash tools/publish.sh`
2. Announce on:
1. Discord: Bevy, #dev-announcements

#### RC Post-Release

1. Update Bevy version used for Bevy book code validation to latest release.