|
| 1 | +# Release |
| 2 | + |
| 3 | +This document explains the current release procedure for the Glide project. |
| 4 | + |
| 5 | +A person that handles the release is called the release manager. |
| 6 | + |
| 7 | +The release version should be picked based on the previous version and changes that are going to be released: |
| 8 | +- If the previous version was `0.0.3` and changeset doesn't have breaking changes in API, the next version may be either `0.0.4-rc.1`. |
| 9 | +- If the previous version was `0.0.3-rc.2` and changeset doesn't have breaking changes in API, the next version may be either `0.0.3-rc.3` or `0.0.3`. |
| 10 | +- if the previous version was `0.0.3` and changeset has breaking changes in API, the next version may be either `0.1.0-rc.1` or `0.1.0`. |
| 11 | + |
| 12 | +It's encouraged to have a release candidate as an intermediate step in the releasing the "stable" version. |
| 13 | + |
| 14 | +## The release process |
| 15 | + |
| 16 | +The following is step-by-step instruction. |
| 17 | + |
| 18 | +### The release PR |
| 19 | + |
| 20 | +The release manager creates a new pull request from the `develop` branch into the `main`. |
| 21 | + |
| 22 | +### Collect changelog |
| 23 | + |
| 24 | +The changeset from the PR should be reviewed and represented as a changelog in the `CHANGELOG.md` file. |
| 25 | + |
| 26 | +Git can be helpful to summarize changes: |
| 27 | + |
| 28 | +```bash |
| 29 | +git log --pretty=format:"%s (%an)" {LAST_VERSION_TAG}..HEAD |
| 30 | +``` |
| 31 | + |
| 32 | +Sort out all changes to the categories they belong to. |
| 33 | + |
| 34 | +### Update the release PR description |
| 35 | + |
| 36 | +Use the created changelog to update the PR description. |
| 37 | + |
| 38 | +### Merge the release PR |
| 39 | + |
| 40 | +Once all checks are green on the Release PR, you can merge it into the main. |
| 41 | +When squashing the pull request, please specify the same changelog you have added to the PR description. |
| 42 | + |
| 43 | +### Tag the merge commit |
| 44 | + |
| 45 | +Tag the merge commit in the main branch using the release version like `0.1.0-rc.1`. |
| 46 | + |
| 47 | +That should trigger a deployment pipeline that can be checked under https://github.com/EinStack/glide/actions. |
| 48 | + |
| 49 | +Wait until the pipeline is done or failed. |
| 50 | + |
| 51 | +### Create a GitHub release |
| 52 | + |
| 53 | +The release manager then creates a release in GitHub for the released version. |
| 54 | +The GitHub release should contain the same changelog message we have used in the release PR description. |
| 55 | + |
| 56 | +The release should be marked as a pre-release if the version is a release candidate or a stable release otherwise. |
| 57 | + |
| 58 | +Feel free to announce the release via creating a discussion (there is a checkbox for that on the new GitHub release form). |
| 59 | + |
| 60 | +### Spread a word about the release |
| 61 | + |
| 62 | +The release manager should spread a word about the release in the Discord community space. |
| 63 | + |
| 64 | +Please use the `#announcements` channel for announcing stable releases. |
| 65 | +You can use `#general` to announce release candidates. |
| 66 | + |
| 67 | +Be sure to do shutouts for people who spend their time improving the project. |
| 68 | + |
| 69 | +| Releases | Release Manager | |
| 70 | +|------------------|-----------------| |
| 71 | +| 0.0.1-0.1.0-rc.1 | @roma-glushko | |
0 commit comments