Skip to content

Latest commit

 

History

History
84 lines (65 loc) · 4.23 KB

RELEASING.rst

File metadata and controls

84 lines (65 loc) · 4.23 KB

Releasing scheil

Create a release of scheil

To release a new version of scheil:

These steps assume that 0.1 is the most recently tagged version number and 0.2 is the next version number to be released. Replace their values with the last public release's version number and the new version number as appropriate.

  1. Determine what the next version number should be using semantic versioning.
  2. Resolve or defer all pull requests and issues tagged with the upcoming version milestone.
  3. git stash to save any uncommitted work.
  4. git checkout master
  5. git pull to make sure you haven't missed any last-minute commits. After this point, nothing else is making it into this version.
  6. pytest to ensure that all tests pass locally.
  7. sphinx-apidoc -f -H 'API Documentation' -o docs/api/ scheil to regenerate the API documentation.
  8. Update CHANGES.rst with a human-readable list of changes since the last commit. git log --oneline --no-decorate --color 0.1^..master can be used to list the changes since the last version.
  9. git add docs/api CHANGES.rst to stage the updated documentation.
  10. git commit -m "REL: 0.2" to commit the changes.
  11. git push origin master
  12. Verify that all continuous integration test and build workflows pass.
  13. Create a release on GitHub
    1. Go to https://github.com/pycalphad/scheil/releases/new
    2. Set the "Tag version" field to 0.2.
    3. Set the branch target to master.
    4. Set the "Release title" to scheil 0.2.
    5. Leave the description box blank.
    6. If this version is a pre-release, check the "This is a pre-release" box.
    7. Click "Publish release".
  14. The new version will be available on PyPI when the Build and deploy to PyPI workflow on GitHub Actions finishes successfully.

Deploy to PyPI (manually)

Warning

DO NOT FOLLOW THESE STEPS unless the GitHub Actions deployment workflow is broken. Creating a GitHub release should trigger the Build and deploy to PyPI workflow on GitHub Actions that will upload source and platform-dependent wheel distributions automatically.

To release a source distribution to PyPI:

  1. If deploying for the first time: pip install twine build
  2. rm -R dist/* on Linux/OSX or del dist/* on Windows
  3. git checkout master to checkout the latest version
  4. git pull
  5. git log to verify the repository state matches the newly created tag
  6. python -m build --sdist
  7. Make sure that the script correctly detected the new version exactly and not a dirty / revised state of the repo.
  8. twine upload dist/* to upload (assumes a correctly configured ~/.pypirc file)

Deploy to conda-forge (manually)

The conda-forge autotick bot will automatically open a pull request in the conda-forge/scheil-feedstock repository after the package has been uploaded to PyPI. This usually happens in within an hour of the PyPI release. If the build succeeds, the PR will be merged automatically and scheil will usually be available in an hour or two.

Warning

DO NOT FOLLOW THESE STEPS unless the pull request opened by the conda-forge autotick bot on the conda-forge/scheil-feedstock was not merged automatically and a new PR needs to be built manually.

Start with the commit checked out which was tagged with the new version.

  1. Generate the SHA256 hash of the build artifact (tarball) submitted to PyPI. Alternatively, the hashes can be found by clicking the "View" button for the source distribution in the PyPI download files table.
  2. Fork the conda-forge/scheil-feedstock repo.
  3. Update scheil version and sha256 strings in the recipe/meta.yaml file.
  4. If any of the dependencies changed since the last release, make sure to update the recipe/meta.yaml file.
  5. Submit a pull request to the main scheil feedstock repo.
  6. Once the build completes successfully, merge the pull request.