Skip to content

Latest commit

 

History

History
117 lines (84 loc) · 7.84 KB

release.md

File metadata and controls

117 lines (84 loc) · 7.84 KB
Raw

Release Process

0. Pre-Release Checklist

Before starting the release process, verify the following:

Version Numbering

Woodwork uses semantic versioning. Every release has a major, minor and patch version number, and are displayed like so: <majorVersion>.<minorVersion>.<patchVersion>.

In certain instances, it may be necessary to create a backport release. This is when commits from a newer version of a library are ported to an older version of the software and then released. This occurs when anything but the latest commit on main is used as the target for release, but can go so far as to add a further patch release, such as 0.11.2, to be released after a 0.12.0 version had already been released. If a backport release is being performed, please see the Backport Release Guide for instructions on how to proceed, as some steps from this guide should be performed differently.

If you'd like to create a development release, which won't be deployed to pypi and conda and marked as a generally-available production release, please add a "dev" prefix to the patch version, i.e. X.X.devX. Note this claims the patch number--if the previous release was 0.12.0, a subsequent dev release would be 0.12.dev1, and the following release would be 0.12.2, not 0.12.1. Development releases deploy to test.pypi.org instead of to pypi.org.

1. Create Woodwork release on Github

Create release branch

  1. Branch off of Woodwork 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 number

  1. Bump __version__ in woodwork/version.py, and woodwork/tests/test_version.py.

Update Release Notes

  1. Replace "Future Release" in docs/source/release_notes.rst with the current date

    v0.13.3 Sep 28, 2020
====================

  2. Remove any unused Release Notes sections for this release (e.g. Fixes, Testing Changes)

  3. Add yourself to the list of contributors to this release and put the contributors in alphabetical order

  4. The release PR does not need to be mentioned in the list of changes

  5. 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:

Create Release PR

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:

  • 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 2 (Github Release) is complete.

After merging, verify again that ReadtheDocs "latest" is correct.

2. Create Github Release

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

Release on conda-forge

In order to release on conda-forge, you can either wait for a bot to create a pull request, or manually kickoff the creation with GitHub Actions

Option a: Use a GitHub Action workflow

  1. 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.
  2. Once the job has been completed, you will see summary output, with a URL.
  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 woodwork/pyproject.toml.
    • The test['requires'] (in recipe/meta.yml) matches the [project.optional-dependencies]['test'] in woodwork/pyproject.toml
  4. Satisfy the conditions in pull request description and merge it if the CI passes.

Option b: Waiting for bot to create new PR

  1. A bot should automatically create a new PR in conda-forge/woodwork-feedstock - note, the PR may take up to a few hours to be created
  2. Update requirements changes in recipe/meta.yaml (bot should have handled version and source links on its own)
  3. After tests pass, a maintainer will merge the PR in

Miscellaneous

Add new maintainers to woodwwork-feedstock

Per the instructions here:

  1. Ask an existing maintainer to create an issue on the repo.
    • Select Bot commands and put the following title (change username): @conda-forge-admin, please add user @username
  2. A PR will be auto-created on the repo, and will need to be merged by an existing maintainer.
  3. The new user will need to check their email for an invite link to click, which should be https://github.com/conda-forge