Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Document the release process #2371

Merged
merged 4 commits into from
Sep 14, 2024
Merged

Document the release process #2371

Changes from 3 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
8f2a4d9
Document the release process
intgr Sep 13, 2024
43f58a8
Fix typo
intgr Sep 13, 2024
c30d035
Also describe 'release notes reminder' label
intgr Sep 13, 2024
aa9cd76
Update CONTRIBUTING.md
intgr Sep 14, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 33 additions & 0 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -115,3 +115,36 @@ If it does, please add the new generic class to the `_need_generic` list in the
We only add hints for private attributes when it has some demonstrated real-world use case.
That means from a third-party package or some well described snippet for a project.
This rule helps us avoid tying in too closely to Django’s undocumented internals.


## Releasing `django-stubs`

1. Open a pull request that updates `setup.py`, `ext/setup.py` and `README.md`
(anyone can open this PR, not just maintainers):

- Increase `version=` value within `setup(...)` call in **both** files. The versions must be in sync.
- Update `django-stubs-ext>=` dependency in root `setup.py` to the same version number.
- Version number `major.minor.patch` is formed as follows:

`major.minor` version must match newest supported Django release.

`patch` is sequentially increasing for each stubs release. Reset to `0` if `major.minor` was updated.

- Use pull request title "Version x.y.z release" by convention.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I notice now that flaeppe has been using PR title "Prepare for a release `5.0.1`". I don't have strong feelings either way. Except for the fact that the "a" there seems ungrammatical and can be omitted.

- Add a new row at the top of ['Version compatibility' table in README.md](README.md#version-compatibility).

2. Ensure the CI succeeds. A maintainer must merge this PR. If it's just a version bump, no need
to wait for a second maintainer's approval.

3. A maintainer must [сreate a new GitHub release](https://github.com/typeddjango/django-stubs/releases/new):

- Under "Choose a tag" enter the new version number. Do **not** use `v` prefix.
- Click "Generate release notes".
- Look for merged PRs with the ['release notes reminder' label](https://github.com/typeddjango/django-stubs/issues?q=is%3Aopen+is%3Aissue+label%3A%22release+notes+reminder%22)
and move them to a separate section at the top, so that they stand out. Remove the label from PRs.
- Delete all release notes lines containing `by @pre-commit-ci` or `by @dependabot`, as these
are irrelevant for our users.
Comment on lines +145 to +146
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haven't done this for the last few releases. It's an additional manual step, but IMO release notes are too noisy if these are included.


4. Once you feel brave enough, click "Publish release".

5. Check that the [release workflow](https://github.com/typeddjango/django-stubs/actions/workflows/release.yml) succeeds.
Loading