Release process

Barman release process

This page documents the process of making a new Barman release. It is intended for the Barman maintainers.

Source code changes

• Run scripts/set-version.sh x.yy YYYY-MM-DD to set the version
• Write NEWS
• Update AUTHORS, README.rst
• Update Barman metadata in setup.py
• Commit all the changes
• Tag the version with scripts/release.sh (creates a release/x.yy tag)
• Push the tagged version: git push --tags origin master
• Create a new release on Github

Packaging

At present, although the built Barman packages are available to everyone from dl.enterprisedb.com, the package builds are performed in a closed 2ndQ/EDB CI system (we intend to move these actions to Github in future).

• Update deb/debian/changelog and rpm/barman.spectemplate in the barman-packaging repository
• Commit the changes
• Tag and push: git tag release/x.yy-1 && git push --tags origin master
• Start a release build in CI using "refs/tags/release/x.yy" for the source tag, and "refs/tags/release/x.yy-1" for the packaging tag, with the "Is release" checkbox selected.
• Wait until the build and tests complete and the artefacts (source tarball, RPM/DEB packages) are generated.
• Create a new release on the EDB customer portal

PyPI

• Run rm -rf build dist to remove old build artifacts
• Run ./setup.py sdist to generate a source tarball under dist/
• Run ./setup.py bdist_wheel to generate a .whl file under dist/
• Run twine upload -s dist/*

In practice, we do not use sdist directly, but copy the CI-generated release source tarball into dist/ and run bdist_wheel as described above, so that we publish exactly the same source tarball everywhere (Github, PyPI).

Miscellaneous

• Push update to pgbarman.org, including post announcing release
• Request PGDG RPMs via redmine
• Upload Debian package to PGDG APT repository