Skip to content

Do a new release

Wolfgang Kaltz edited this page Jan 22, 2020 · 18 revisions

Doing a new release

Quality check

  • Be sure to be working on master branch, and do git pull
  • Check release number: Edit setup.py -> check version number is target number
  • If a new number is needed, choose a version number. To see which version was previously published, do pip search pyramid_oereb (or check on pypi.org). To see all versions that have been previously published, use the following trick: pip install pyramid_oereb==999
  • Delete all local docker images and do a make clean-all
  • Do a make serve locally and check that json, xml and pdf generation are functional:
  • Update migration notes (file doc/source/changes.rst), if applicable, and edit the changelog (file CHANGES.rst)
  • Do a make doc, and check quality of doc (in local browser)
  • Do a make checks
  • Commit doc changes; you can push them right away, unless you are unsure about some points, in which case you can go through the normal pull request process.

Set a version tag

  • Check that you are on master branch and up-to-date.
  • Choose a version number, beginning with “v” (for example v1.4.0) to be consistent with previous releases
  • do git tag <version_number>; git push origin <version_number>
  • Check that this tag setting triggers a release by Travis CI,
    • On PyPI
    • On docker hub
    • Note that this may take quite some time! (the release pushes are done by Travis, at the end of the CI of the latest push)

Increment version number in source

  • Edit setup.py to increment version number (for new daily builds) and push right away, so that next daily builds have higher number

GitHub release notes

Set release notes in GitHub user interface:

  • Click on Code, Releases, Draft a new release
  • Choose the tag version you created for the release (see above)
  • Choose a release title (see previous releases for examples) and click on "Publish release"

Mapfish Print templates release

If changes affected the Mapfish Print proxy or the templates, create a new tag and release with the same name at openoereb/pyramid_oereb_mfp.

Community communication

If CI is clean and release is present on both platforms (pypi and dockerhub), communicate to the community -> this is handled via Clemens, send him an e-mail to inform him when everything OK

Troubleshooting

  • If you need to re-do everything, delete the tag by doing git tag -d <version-number>; git push origin :refs/tags/<version-number>
  • When re-doing things, careful, as it may trigger actually useless/confusing Travis CI jobs -> stop them manually, and keep only the one coming from the tag setting
Clone this wiki locally