Skip to content

How to make a release

Michael Weiser edited this page May 10, 2022 · 13 revisions

git

  • Resolve all issues associated with the milestone
  • Merge all pull requests associated with the milestone into master
  • Create a feature branch in a forked repo for the new release and on that branch:
    • Bump the version
    • Update the ASCII art in __init__.py with figlet :)
    • Update the change log
  • Open and merge a pull request to merge the release changes into master
  • On the main GitHub repo:
    • Create a new release branch named after the version (e.g. 1.7) in anticipation of hot fixes for that release later on

    • Tag the new state of master with the release number and a message (annotated tag), e.g. v1.7 and Release 1.7: git tag -a -m 'Release 1.7' v1.7

      The latter is necessary to make places where git describe is used correctly show the relation to the last release, i.e. v1.7 instead of v1.6.1-204-g911ebe0. git submodule is one such place, scripts extracting exactly this information might be another.

      TODO: Signed tags are implicitly annotated tags and switching to signed releases would be a good thing to do [tm] in itself.

    • push the new branch: git push --all

    • push the new tag: git push --tags

  • Add the relevant change log entries to the release info on GitHub by drafting a new release as per https://help.github.com/en/articles/creating-releases, select the release's git tag as base
  • Close the milestone of the current release
  • Potentially create a new milestone for the next release
  • Add the new branch to the weekly scheduled workflow via a follow-up PR so we spot regressions caused by changes in external dependencies.

PyPi Upload

cd /path/to/PeekabooAV/
git checkout v1.7
git clean -id
python setup.py sdist
twine upload -u peekabooav dist/*

Check your work here https://pypi.org/project/PeekabooAV/.

Note: Ensure that you have a clean workspace before building distributions, since any uncommited changes in your local workspace are included in the distribution.

Installer

The Installer should get its own release corresponding to the new PeekabooAV release, if required. The rule is that point releases of both are independent. The Installer always installs the latest point release of the corresponding minor release. So as long as no changes to the Installer are required to be able to correctly install a new point release of PeekabooAV, no release is necessary.

For new major or minor releases of PeekabooAV, a corresponding release of the Installer should be done.

Checklist:

  • increase major or minor version in tag name in README.md and pstrap.sh
  • raise the pip version constraint in group_vars/all.yml to the next minor release, e.g. 2.2 if minor relase 2.1 is the current (note and understand the less-than operator)
  • create and merge a PR with these changes
  • after merge, tag the new release on the main repo
  • author a new release as described for PeekabooAV above