This chapter describes how to release a new version of Bareos. The documentation is limited to the changes that need to be done to the sources and the git repository. Building and distributing source and binary packages is not the scope of this chapter.
Consider this a step-by-step manual. The sections are meant to be carried out in that order.
Deciding for a version number¶
When you release you will usually need at least two version numbers: the version you’re going to release and the version that will follow after that version. For details on the numbering-scheme, take a look at Bareos Version Numbers and Releases.
Usually, you will have an existing work-in-progress tag that generates pre-release version numbers for your branch. So the version you’re going to release is probably the final version for that pre-release.
Preparing the release notes¶
In Version >= 20.0.0 release notes will be kept in
The “Unreleased” section in that file will automatically become the release notes and a new “Unreleased” section will be added afterwards.
How does it work in detail?¶
When you run
devtools/prepare-release.sh the “Unreleased” section will be renamed to the current release by
All links to pull requests, issues, etc. will be automatically updated by
After the release has been made
devtools/new-changelog-release.sh will be called again to add the new “Unreleased” section that will be added to the commit for the work-in-progress tag.
Update version-dependent files¶
There are version-dependent files in the Bareos sources that might need your attention.
The file is in either
Whenever the database schema version changes this file must be updated.
Usually the developer who did a schema change should have done this.
However, please double-check and add or update the version mapping if needed.
Publishing the release¶
To actually publish the release you push the commits and tags created earlier to GitHub. After you have reviewed the commits and tags that have been set in the previous release and made sure all branch pointers point to the right places (please double- and triple-check this) and you’re on the correct branch, you can push the changes to GitHub.
For the release branch: First push the branch
git push <remote>, then push the release-tag
git push <remote> <release-tag> and if applicable push the WIP-tag
git push <remote> <WIP-tag>.
For the master: If this is a new major release you also need to push master and the new WIP-tag for master.
Updating GitHub Release¶
Pushing a tag to GitHub will implicitly create a release on the project’s list of releases. The release information there is incomplete and should be updated.
Go to the list described above, select your release-tag and press “Edit tag”. In the form enter “Release X.Y.Z” for “Release title” and add the URL of the release notes to “Describe this release”. If you’re releasing a pre-release (anything with a tilde in the version number) check the “This is a pre-release” box. Apply the changes by pressing “Save”.