blob: 73eaaef6218b02dcf49719f4912ba0259303ffaa (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
|
# Releasing an astroid version
So, you want to release the `X.Y.Z` version of astroid ?
## Releasing a major or minor version
**Before releasing a major or minor version check if there are any unreleased commits on
the maintenance branch. If so, release a last patch release first. See
`Releasing a patch version`.**
- Remove the empty changelog for the last unreleased patch version `X.Y-1.Z'`. (For
example: `v2.3.5`)
- Check the result of `git diff vX.Y-1.Z' ChangeLog`. (For example:
`git diff v2.3.4 ChangeLog`)
- Install the release dependencies: `pip3 install -r requirements_minimal.txt`
- Bump the version and release by using `tbump X.Y.0 --no-push --no-tag`. (For example:
`tbump 2.4.0 --no-push --no-tag`)
- Check the commit created with `git show` amend the commit if required.
- Move the `main` branch up to a dev version with `tbump`:
```bash
tbump X.Y+1.0-dev0 --no-tag --no-push # You can interrupt after the first step
git commit -am "Upgrade the version to x.y+1.0-dev0 following x.y.0 release"
```
For example:
```bash
tbump 2.5.0-dev0 --no-tag --no-push
git commit -am "Upgrade the version to 2.5.0-dev0 following 2.4.0 release"
```
Check the commit and then push to a release branch
- Open a merge request with the two commits (no one can push directly on `main`)
- Trigger the "release tests" workflow in GitHub Actions.
- After the merge, recover the merged commits on `main` and tag the first one (the
version should be `X.Y.Z`) as `vX.Y.Z` (For example: `v2.4.0`)
- Push the tag.
- Release the version on GitHub with the same name as the tag and copy and paste the
appropriate changelog in the description. This triggers the PyPI release.
- Delete the `maintenance/X.Y-1.x` branch. (For example: `maintenance/2.3.x`)
- Create a `maintenance/X.Y.x` (For example: `maintenance/2.4.x` from the `v2.4.0` tag.)
## Backporting a fix from `main` to the maintenance branch
Whenever a PR on `main` should be released in a patch release on the current maintenance
branch:
- Label the PR with `backport maintenance/X.Y-1.x`. (For example
`backport maintenance/2.3.x`)
- Squash the PR before merging (alternatively rebase if there's a single commit)
- (If the automated cherry-pick has conflicts)
- Add a `Needs backport` label and do it manually.
- You might alternatively also:
- Cherry-pick the changes that create the conflict if it's not a new feature before
doing the original PR cherry-pick manually.
- Decide to wait for the next minor to release the PR
- In any case upgrade the milestones in the original PR and newly cherry-picked PR
to match reality.
- Release a patch version
## Releasing a patch version
We release patch versions when a crash or a bug is fixed on the main branch and has been
cherry-picked on the maintenance branch.
- Check the result of `git diff vX.Y-1.Z-1 ChangeLog`. (For example:
`git diff v2.3.4 ChangeLog`)
- Install the release dependencies: `pip3 install -r requirements_minimal.txt`
- Bump the version and release by using `tbump X.Y-1.Z --no-push`. (For example:
`tbump 2.3.5 --no-push`)
- Check the result visually with `git show`.
- Open a merge request to run the CI tests for this branch
- Create and push the tag.
- Release the version on GitHub with the same name as the tag and copy and paste the
appropriate changelog in the description. This triggers the PyPI release.
- Merge the `maintenance/X.Y.x` branch on the main branch. The main branch should have
the changelog for `X.Y-1.Z+1` (For example `v2.3.6`). This merge is required so
`pre-commit autoupdate` works for pylint.
- Fix version conflicts properly, or bump the version to `X.Y.0-devZ` (For example:
`2.4.0-dev6`) before pushing on the main branch
## Milestone handling
We move issues that were not done to the next milestone and block releases only if there
are any open issues labelled as `blocker`.
|
