alex/winit-sonoma-fix
1
0
Fork 0
mirror of https://github.com/italicsjenga/winit-sonoma-fix.git synced 2024-12-23 13:51:30 +11:00
Code Issues Packages Projects Releases Wiki Activity

Add release process

Browse source 
This should maintainers to handle releases and
establish a non-blocking workflow.

Fixes #2454.
This commit is contained in:
Kirill Chibisov 2022-09-11 16:20:09 +03:00 committed by GitHub
parent 5d2aca90bd
commit 3b56b0e76f
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 19 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

28
CONTRIBUTING.md
View file

@ -48,15 +48,25 @@ The current maintainers are listed in the [CODEOWNERS](.github/CODEOWNERS) file.
If you are interested in being pinged when testing is needed for a certain platform, please add yourself to the [Testers and Contributors](https://github.com/rust-windowing/winit/wiki/Testers-and-Contributors) table! If you are interested in being pinged when testing is needed for a certain platform, please add yourself to the [Testers and Contributors](https://github.com/rust-windowing/winit/wiki/Testers-and-Contributors) table!
## Making a new release ## Release process
If you believe a new release is warranted, you can make a pull-request with: Given that winit is a widely used library we should be able to make a patch
- An updated version number (remember to change the version everywhere it is used). releases at any time we want without blocking the development of new features.
- A new section in the changelog (below the `# Unreleased` section).
This gives contributors an opportunity to squeeze in an extra PR or two that they feel is valuable To achieve these goals, a new branch is created for every new release. Releases
enough to warrant blocking the release a little. and later patch releases are committed and tagged in this branch.
Once the PR is merged, a maintainer will create a new tag matching the version name (e.g. `v0.26.1`), The exact steps for an exemplary `0.2.0` release might look like this:
and a CI job will automatically release the new version. Remember that the release date in the 1. Initially the version on the latest master is `0.1.0`
changelog must be kept in check with the actual release date. 2. A new `v0.2.x` branch is created for the release
3. In the branch, the version is bumped to `v0.2.0`
4. The new commit in the branch is tagged `v0.2.0`
5. The version is pushed to crates.io
6. A GitHub release is created for the `v0.2.0` tag
7. On master, the version is bumped to `0.2.0` and the CHANGELOG is updated
When doing a patch release the process is similar:
1. Initially the version of the latest release is `0.2.0`
2. Checkout the `v0.2.x` branch
3. Cherry-pick the required non-breaking changes into the `v0.2.x`
4. Follow steps 3-7 of the regular release example