Skip to content

How to do afdko releases

Miguel Sousa edited this page Jun 20, 2018 · 2 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 most recent tag.

Pre-releases

  • Tag the last commit of the develop branch according to the pre-release tag requirements defined below
  • Push the tag to the remote origin
  • The tag must have an Alpha or Beta pre-release segment {a|b}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

Release candidates

  • Issuing the first release candidate version requires several steps:
    1. Close the Project for the current sprint
    2. Commit the changes to NEWS.md in the develop branch (example commit)
      • DO NOT use [skip ci] in the commit message
    3. Make a new branch named release (from develop)
    4. Push the release branch to the remote origin (i.e. to GitHub)
    5. Tag the last commit of the release branch according to the release candidate tag requirements defined below
    6. Push the tag to the remote origin
  • Subsequent release candidate versions require different steps. If a significant problem was discovered in the most recent release candidate version, do the following:
    1. Commit the fixes to the release branch
    2. Tag the last commit of the release branch (see requirements below)
    3. Push the new tag to the remote origin
    4. Cherry-pick the new commits to the develop branch
  • The tag must have a Release Candidate pre-release segment {rc}N
  • Examples of sequential release candidate tags (assuming 2.7.1b1 was the last tag):
    • 2.7.1rc
    • 2.7.1rc1
    • 2.7.1rc2

Final releases

  • Wait until the last release candidate version is about one week old
  • Issuing the final release version requires several steps:
    1. Update the date of the most recent version in NEWS.md
    2. Commit the NEWS.md change to the release branch
    3. Cherry-pick the commit to the develop branch
    4. Merge the release branch into the master branch
    5. Delete the release branch
    6. Tag the merge commit according to the final release tag requirements defined below
  • Remove pre-release and release candidate tags from local and remote repositories
  • Delete draft releases from GitHub
  • Delete pre-release and release candidate releases from PyPI
  • 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.

Clone this wiki locally