Before starting the release process, verify the following:
- All work required for this release has been completed and the team is ready to release.
- All Github Actions Tests are green on main.
- Get agreement on the version number to use for the release.
Premium Primitives uses semantic versioning. Every release has a major, minor and patch version number, and are displayed like so: <majorVersion>.<minorVersion>.<patchVersion>
.
- Branch off of premium_primitives main. For the branch name, please use "release_vX.Y.Z" as the naming scheme (e.g. "release_v0.13.3"). Doing so will bypass our release notes checkin test which requires all other PRs to add a release note entry.
- Bump
__version__
inpremium_primitives/version.py
, andpremium_primitives/tests/test_version.py
.
-
Replace "Future Release" in
docs/source/release_notes.rst
with the current datev0.13.3 Sep 28, 2020 ====================
-
Remove any unused Release Notes sections for this release (e.g. Fixes, Testing Changes)
-
Add yourself to the list of contributors to this release and put the contributors in alphabetical order
-
The release PR does not need to be mentioned in the list of changes
-
Add a commented out "Future Release" section with all of the Release Notes sections above the current section
.. Future Release ============== * Enhancements * Fixes * Changes * Documentation Changes * Testing Changes .. Thanks to the following people for contributing to this release:
A release pr should have the version number as the title and the release notes for that release as the PR body text. The contributors list is not necessary. The special sphinx docs syntax (:pr:`547`) needs to be changed to github link syntax (#547).
Checklist before merging:
- The title of the PR is the version number.
- All tests are currently green on checkin and on
main
. - The ReadtheDocs build for the release PR branch has passed, and the resulting docs contain the expected release notes.
- PR has been reviewed and approved.
- Confirm with the team that
main
will be frozen until step 3 (Github Release) is complete.
After merging, verify again that ReadtheDocs "latest" is correct.
After the release pull request has been merged into the main
branch, it is time draft the github release. Example release
- The target should be the
main
branch - The tag should be the version number with a v prefix (e.g. v0.13.3)
- Release title is the same as the tag
- Release description should be the full Release Notes updates for the release, including the line thanking contributors. Contributors should also have their links changed from the docs syntax (:user:`gsheni`) to github syntax (@gsheni)
- This is not a pre-release
- Publishing the release will automatically upload the package to PyPI
In order to release on conda-forge, you can either wait for a bot to create a pull request, or use a GitHub Actions workflow
- After the package has been uploaded on PyPI, the Create Feedstock Pull Request workflow should automatically kickoff a job.
- If it does not, go here
- Click Run workflow and input the letter
v
followed by the release version (e.g.v0.13.3
) - Kickoff the GitHub Action, and monitor the Job Summary.
- Once the job has been completed, you will see summary output, with a URL.
- Visit that URL and create a pull request.
- Alternatively, create the pull request by clicking the branch name (e.g. -
v0.13.3
):
- Verify that the PR has the following:
- The
build['number']
is 0 (in recipe/meta.yml). - The
requirements['run']
(in recipe/meta.yml) matches the[project]['dependencies']
in premium_primitives/pyproject.toml. - The
test['requires']
(in recipe/meta.yml) matches the[project.optional-dependencies]['test']
in premium_primitives/pyproject.toml
- The
- Satisfy the conditions in pull request description and merge it if the CI passes.
- A bot should automatically create a new PR in conda-forge/premium_primitives-feedstock - note, the PR may take up to a few hours to be created
- Update requirements changes in
recipe/meta.yaml
(bot should have handled version and source links on its own) - After tests pass, a maintainer will merge the PR in
Per the instructions here:
- Ask an existing maintainer to create an issue on the repo.
a. Select Bot commands and put the following title (change
username
):
@conda-forge-admin, please add user @username
- A PR will be auto-created on the repo, and will need to be merged by an existing maintainer.
- The new user will need to check their email for an invite link to click, which should be https://github.com/conda-forge