Skip to main content

release

Release a new djoser version - review the diff since the last release, write the changelog entry, bump the version, verify everything locally, and prepare the tag for the user to push

Informações da origem

Repositório
sunscrapers/djoser
Última atividade na origem
1 de agosto de 2026 às 15:31
Idioma detectado do SKILL.md
inglês
Estrelas
2.679
Forks
468

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

Exibindo SKILL.md

SKILL.md
Instruções da origem · Visualização somente leitura
name
release
description
Release a new djoser version - review the diff since the last release, write the changelog entry, bump the version, verify everything locally, and prepare the tag for the user to push
# Release a new djoser version Prepare and verify a release end-to-end. The user's `git push origin X.Y.Z` is the only action that triggers anything external: the tag push starts the `Release` workflow (validate → test matrix → build → PyPI → GitHub release). Never push the tag yourself. Never run `uv publish` or `gh release create` manually — CI does that. Work through the stages in order. Do not skip a verification because it "probably passes"; the whole point of this skill is that the release is checked before the tag exists. ## 1. Establish scope 1. `git fetch origin` and make sure the local `master` matches `origin/master` with a clean working tree. 2. Find the last release: `LAST_TAG=$(git describe --tags --abbrev=0 origin/master)`. 3. Review everything since then: `git log --oneline $LAST_TAG..origin/master` and the full `git diff $LAST_TAG..origin/master`. Read the diff, not just the commit subjects — changelog entries must describe user-facing behavior, and commit messages sometimes undersell or oversell what changed. 4. Summarize the user-facing changes for the user and agree on the new version number: - patch = bug fixes, minor = backwards-compatible features, major = breaking changes - a PEP 440 pre-release suffix (`a1`, `b1`, `rc1`) publishes to PyPI like any other version, but pip/uv never resolve to it without `--pre` or an exact pin; suggest one first when the diff is large or risky. Write the changelog entry under the final `X.Y.Z` heading — CI falls back to it for the pre-release, and the changelog carries no pre-release sections. 5. If there is nothing user-facing to release, say so and stop. ## 2. Prepare the release branch 1. `git checkout -b release/X.Y.Z origin/master` 2. Set the version in `pyproject.toml` (`[project] version`), then run `uv lock` — the lockfile records the project's own version and the CI lock-file check fails if it is stale. 3. Update `CHANGELOG.rst`: - new section at the top, matching the existing format exactly: overline/underline dashes, `` `X.Y.Z`_ (YYYY-MM-DD) `` heading, `*` bullets with issue/PR links - a `.. _X.Y.Z: https://github.com/sunscrapers/djoser/compare/PREV...X.Y.Z` link definition at the bottom - every notable change found in stage 1 must be reflected; nothing in the entry may be missing from the diff - the CI extracts this section verbatim as the GitHub release notes, and fails a stable release if the section is missing - `docs/source/changelog.rst` includes this file, so the entry is also published on Read the Docs — there is no second place to edit, but the entry must be valid RST (escape `` ``**kwargs`` ``-style markup) or the docs build warns and renders it wrong 4. Show the changelog entry to the user and get approval before continuing. ## 3. Verify locally Run all of these; all must pass: 1. `make test` — full suite 2. `make run-hooks` — pre-commit checks (needs `.venv/bin` on `PATH`) 3. `make build` — translations compile and the package builds 4. `uv lock --check` — lockfile consistent with `pyproject.toml` 5. `make docs` — the docs build, including the rendered changelog entry; it must not add new warnings Report the results honestly; a failure here aborts the release until fixed. ## 4. Land the bump on master 1. Commit `pyproject.toml`, `uv.lock` and `CHANGELOG.rst` as `Bump version to X.Y.Z`. 2. Push the branch and open a PR against `master`; wait for the user to merge it (the repo squash-merges). 3. After the merge: `git fetch origin` and confirm `origin/master` now carries the bump (`uv version --short` on that commit equals `X.Y.Z`). ## 5. Tag and hand over 1. Tag the merged commit: `git tag X.Y.Z origin/master` — tags are bare `X.Y.Z`, no `v` prefix, matching every historical djoser tag (stable tags must point at a commit on `master` — CI enforces this). 2. Do NOT push the tag. Tell the user to run: ```bash git push origin X.Y.Z ``` 3. Point them at the Actions tab to watch the `Release` workflow. If it fails, the fix path is: correct the problem, `git push --delete origin X.Y.Z`, delete the local tag, and re-run this skill's relevant stages.
Ver no GitHub