Skip to content

DOC: Add Release Readiness step to release process docs #1450

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

Open
rlundeen2 wants to merge 2 commits into
base: main
Choose a base branch
from
Open

DOC: Add Release Readiness step to release process docs #1450

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
749cbcb
Add Release Readiness step to release process docs
rlundeen2 Mar 10, 2026
65184a9
Merge branch 'main' into users/rlundeen/2026_03_10_release_process_up…
ValbuenaVC Mar 10, 2026
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: 20 additions & 13 deletions doc/contributing/11_release_process.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,16 @@ email address listed in pyproject.toml

Follow the instructions according to the order provided.

## 1. Decide the Next Version
## 1. Release Readiness

Before starting the release process, verify the codebase is in a healthy state.

- **Check for pending changes.** Ask other PyRIT maintainers whether they have any in-flight changes that should land before the release.
- **Verify build pipelines.** Confirm that all integration tests and end-to-end tests are passing in the CI pipelines. If any tests are failing, fix them before proceeding.
- **Verify pyrit-internal is up to date.** Follow the instructions at [aka.ms/internal-release](https://aka.ms/internal-release) to ensure the internal package is current.
Copy link
Contributor

@ValbuenaVC ValbuenaVC Mar 10, 2026

Choose a reason for hiding this comment

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

Nit: should we be more explicit that this link is available only for Microsoft FTEs with repo access, or is that already obvious from the fact this is only for maintainers?

Copy link
Contributor

@romanlutz romanlutz Mar 10, 2026

Choose a reason for hiding this comment

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

Wouldn't that be post-release? Can't update pyrit-internal with the release version before releasing after all.

Copy link
Contributor Author

@rlundeen2 rlundeen2 Mar 11, 2026

Choose a reason for hiding this comment

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

ah good point, I was thinking about checking everything worked first, but probably makes more sense at the end so we can pin

- **Update scorer metrics.** Run `python .\build_scripts\evaluate_scorers.py` and commit the results so that scorer evaluation metrics are up to date.

## 2. Decide the Next Version

First, decide what the next release version is going to be.
We follow semantic versioning for Python projects; see
Expand Down Expand Up @@ -36,7 +45,7 @@ there should be any postfixes on the release version.
With that in mind, the reason for the release and the set of changes
that happened since the last release will influence the new version number.

## 2. Remove deprecated functionality
## 3. Remove deprecated functionality

If you are incrementing the minor version, search the entire codebase for the new minor
version, e.g., "0.11.0" (no leading "v"),
Expand All @@ -50,14 +59,14 @@ In some cases, we know that the next version will not be a patch upgrade (e.g.,
0.10.0 to 0.10.1) but rather a minor upgrade (0.10.3 to 0.11.0) and we can remove
functionality that is to be deprecated beforehand.
This is preferable but it may not be clear if a release is patch or minor until the full
scope of the release is known (see step 1).
scope of the release is known (see step 2).

## 3. Update the version
## 4. Update the version

### __init__.py, pyproject.toml, and package.json

Set the version in `pyrit/__init__.py`, `pyproject.toml`, and `package.json` to the version
established in step 1.
established in step 2.

### Update README File

Expand All @@ -79,7 +88,7 @@ For directories, update using the "tree" link, e.g.,
This is required for the release branch because PyPI does not pick up
other files besides the README, which results in local links breaking.

## 4. Publish to GitHub
## 5. Publish to GitHub

Commit your changes and push them to the repository on a branch called
`releases/vx.y.z`, then run
Expand All @@ -94,7 +103,7 @@ git push --tags

After pushing the branch to remote, check the release branch to make sure it looks as intended (e.g. check the links in the README work properly).

## 5. Build Package
## 6. Build Package

You'll need the build package to build the project. If it’s not already installed, install it `pip install build`.

Expand Down Expand Up @@ -125,7 +134,7 @@ This should print

> Successfully built pyrit-x.y.z.tar.gz and pyrit-x.y.z-py3-none-any.whl

## 6. Test Built Package
## 7. Test Built Package

This step is crucial to ensure that the new package works out of the box.
Create a new environment with `uv venv --python 3.11`
Copy link
Contributor

@ValbuenaVC ValbuenaVC Mar 10, 2026

Choose a reason for hiding this comment

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

Nit: Just realized this is hardcoded; should we tie this to something or just let it be 3.11 until we deprecate it?

Expand Down Expand Up @@ -164,9 +173,7 @@ git tag -a vx.y.z -m "vx.y.z release" --force # to update the tag to the correct

Note: You may need to build the package again if those changes modify any dependencies, and consider retesting the notebooks if the changes affect them. If you reuse the same environment, it is best to `uv pip uninstall pyrit` to force the reinstall.

Internal maintainers should visit [aka.ms/internal-release](https://aka.ms/internal-release) as well.

## 7. Publish to PyPI
## 8. Publish to PyPI

Create an account on pypi.org if you don't have one yet.
Ask one of the other maintainers to add you to the `pyrit` project on PyPI.
Expand All @@ -183,7 +190,7 @@ If successful, it will print
> View at:
> https://pypi.org/project/pyrit/x.y.z/

## 8. Update main
## 9. Update main

After the release is on PyPI, make sure to create a PR for the `main` branch
where the only changes are:
Expand All @@ -195,7 +202,7 @@ where the only changes are:
The PR should be made from your fork and should be a different branch than the releases branch you created earlier.
This should be something like `x.y.z+1.dev0`.

## 9. Create GitHub Release
## 10. Create GitHub Release

Finally, go to the [releases page](https://github.com/Azure/PyRIT/releases), select "Draft a new release" and the "tag"
for which you want to create the release notes. It should match the version that you just released
Expand Down