Skip to content

How to do afdko releases

Josh Hadley edited this page Feb 24, 2022 · 12 revisions

General requirements

All kinds of releases require tagging a commit.

The tags must follow the versioning scheme defined by PEP 440.

Every new tag must be an increment of the last tag.

Pre-releases

  1. Tag the last commit of the develop branch (or any other branch besides master) according to the pre-release tag requirements defined below:
    • The tag must have an Alpha, Beta or Release Candidate pre-release segment {a|b|(c|rc)}N.
    • Examples of sequential pre-release tags (assuming 2.7.0 was the last tag):
      • 2.7.1a
      • 2.7.1a1
      • 2.7.1a2
      • 2.7.1b
      • 2.7.1b1
      • 2.7.1c
  2. Push the tag to the remote origin.

Final releases

  1. Issue one last pre-release, to make sure all systems are go. This extra step will greatly reduce the changes of a botched final release.
  2. If you have a local branch named master, delete it.
  3. Commit the changes to NEWS.md in the develop branch (example commit).
    • Do NOT use [skip ci] in the commit message.
  4. Push the commit to the origin.
  5. Locally, make a branch of develop called release.
  6. Checkout the origin/master branch.
  7. Locally, merge the release branch into master.
  8. Push the merge commit to the origin.
  9. Tag the merge commit in master according to the final release tag requirements defined below;
    • The tag must not have any pre-release segment.
    • Assuming 2.7.1rc2 was the last tag, the final release tag must be 2.7.1.
    • Make sure you actually push the tag to origin
  10. Delete the local release and master branches.
  11. Remove pre-release and release candidate tags from local and remote repositories (after builds have all completed).
  12. Un-tick the "This is a pre-release" checkbox in the release in GitHub ("Edit Release")
  13. Delete draft releases from GitHub.
  14. Delete pre-release and release candidate releases from PyPI.
  15. Confirm that the release description links to the release's notes in NEWS.md (this is performed automatically by the release workflow; this is just a check).
  16. In GitHub, merge master back into develop to keep them in sync and ensure the release tag is present on develop.