|
1 | 1 | # Release Process |
2 | 2 |
|
3 | | -In order to release a new version of mitreattack-python, follow the process outlined here: |
4 | | - |
5 | | -1. Verify that all changes desired in the next release are present in the `main` branch. |
6 | | - |
7 | | - - If this is for an ATT&CK release, make sure to update the `LATEST_VERSION` in `mitreattack/release_info.py`. |
8 | | - |
9 | | -2. Verify that all changes are documented in the CHANGELOG staged in the `main` branch. |
10 | | -3. Build the _mitreattack-python_ package from source and install it locally: |
11 | | - 1. [Optional] Activate a virtualenv. e.g., `source ./venv/bin/activate` |
12 | | - 2. Uninstall any older/previously installed versions of mitreattack-python: `pip uninstall mitreattack-python` |
13 | | - 3. If you have previously built from source, remove older build artifacts: `rm -rf dist/`. |
14 | | - 4. Build the package: `python setup.py sdist bdist_wheel`. |
15 | | - 5. Lint the wheel contents with [check-wheel-contents](https://github.com/jwodder/check-wheel-contents): `check-wheel-contents dist/` |
16 | | - 6. Install the package locally using pip, and import it in a python session to validate the build: `pip install --find-links=./dist mitreattack-python` |
17 | | - |
18 | | -4. Run the test suite in `/tests/` with pytest. |
19 | | - |
20 | | - ```bash |
21 | | - # must run from the tests/ directory |
22 | | - cd tests/ |
23 | | - pytest --cov=mitreattack --cov-report html |
24 | | - ``` |
25 | | - |
26 | | -5. Edit `setup.py` and increment the version number. |
27 | | - Update other fields in setup.py as necessary (used libraries, etc.) |
28 | | -6. Commit any uncommitted changes. |
29 | | -7. Tag the release: |
30 | | - 1. Tag the `main` branch with the version number - `git tag -a "vA.B.C" -m "mitreattack-python version A.B.C"` |
31 | | - 2. Push both the commit and the tag - `git push`/`git push --tags` |
32 | | -8. Verify that the package uploaded correctly |
33 | | - 1. Check that GitHub Actions succeeded: <https://github.com/mitre-attack/mitreattack-python/actions> |
34 | | - 2. Verify PyPI has expected release: <https://pypi.org/project/mitreattack-python/> |
| 3 | +This guide walks maintainers through releasing a new version of **mitreattack-python**. |
| 4 | +The process uses [Poetry](https://python-poetry.org/) for dependency management and building, |
| 5 | +and [GitHub Actions](https://github.com/mitre-attack/mitreattack-python/actions) for automated linting, testing, and publishing to PyPI. |
| 6 | + |
| 7 | +## 1. Prepare for Release |
| 8 | + |
| 9 | +- Ensure all desired changes are merged into the `main` branch. |
| 10 | +- If releasing for a new ATT&CK version, update `LATEST_VERSION` in `mitreattack/release_info.py`. |
| 11 | + |
| 12 | +## 2. Update Version and Metadata |
| 13 | + |
| 14 | +- Run `cz bump --files-only` |
| 15 | + - This will increment the version field in `pyproject.toml` and other places according to semantic versioning rules. |
| 16 | + - It will also update the `CHANGELOG.md` with all commit messages that are compatible with [Conventional Commits](https://www.conventionalcommits.org). |
| 17 | + - NOTE: You should double-check the generated `CHANGELOG.md` file and make sure it looks good. |
| 18 | +- Update other metadata as needed in `pyproject.toml` (dependencies, etc.). |
| 19 | + |
| 20 | +## 3. Local Validation (Recommended) |
| 21 | + |
| 22 | +Before tagging and pushing, validate the release locally. Following these steps: |
| 23 | + |
| 24 | +```bash |
| 25 | +# Pre-requisite: Install Poetry if not already installed |
| 26 | +# https://python-poetry.org/docs/#installing-with-the-official-installer |
| 27 | +curl -sSL https://install.python-poetry.org | python3 - |
| 28 | + |
| 29 | +# Clean previous builds |
| 30 | +rm -rf dist/ |
| 31 | + |
| 32 | +# Install dependencies (including dev tools) |
| 33 | +poetry install --with=dev |
| 34 | + |
| 35 | +# Lint and format |
| 36 | +poetry run ruff check |
| 37 | +poetry run ruff format --check |
| 38 | + |
| 39 | +# Run tests |
| 40 | +poetry run pytest --cov=mitreattack --cov-report html |
| 41 | + |
| 42 | +# Build the package |
| 43 | +poetry build |
| 44 | + |
| 45 | +# (Optional) Validate wheel contents |
| 46 | +poetry run check-wheel-contents dist/ |
| 47 | + |
| 48 | +# (Optional) Install locally and smoke test |
| 49 | +poetry run pip install --find-links=./dist mitreattack-python |
| 50 | +poetry run python -c "import mitreattack; print(mitreattack.__version__)" |
| 51 | +``` |
| 52 | + |
| 53 | +## 4. Commit and Tag the Release |
| 54 | + |
| 55 | +Perform the following steps to commit your changes, tag the release, and push to GitHub: |
| 56 | + |
| 57 | +```bash |
| 58 | +# Tag the release |
| 59 | +git tag -a "vX.Y.Z" -m "mitreattack-python version X.Y.Z" |
| 60 | + |
| 61 | +# Push the commit and tag |
| 62 | +git push |
| 63 | +git push --tags |
| 64 | +``` |
| 65 | + |
| 66 | +## 5. Automated Publishing |
| 67 | + |
| 68 | +Once the tag is pushed to GitHub: |
| 69 | + |
| 70 | +- GitHub Actions will automatically lint, test, build, and publish the package to PyPI using the workflow in `.github/workflows/lint-publish.yml`. |
| 71 | + |
| 72 | +## 6. Verify Release |
| 73 | + |
| 74 | +Check the [GitHub Actions](https://github.com/mitre-attack/mitreattack-python/actions) for a successful workflow run. |
| 75 | + |
| 76 | +Confirm the new version is available on [PyPI](https://pypi.org/project/mitreattack-python/). |
| 77 | + |
| 78 | +## Notes |
| 79 | + |
| 80 | +- All build and publish steps are handled by GitHub Actions once you push the tag. |
| 81 | +- Manual local validation is optional but recommended before tagging. |
| 82 | +- Readthedocs is used for documentation builds. [Check the status here](https://app.readthedocs.org/projects/mitreattack-python/). |
0 commit comments