You're reading the documentation for an older, but still supported, version of ROS 2. For information on the latest version, please have a look at Jazzy.
Subsequent Releases
This guide explains how to release new versions of ROS packages that have already been released before.
Be part of the release team
If you are not part of the release team that has write access to the release repository, follow Join a release team.
Install dependencies
Install tools that you will use in the upcoming steps according to your platform:
sudo apt install python3-bloom python3-catkin-pkg
sudo dnf install python3-bloom python3-catkin_pkg
pip3 install -U bloom catkin_pkg
Make sure you have rosdep initialized:
sudo rosdep init
rosdep update
Note that the rosdep init
command may fail if it has already been initialized in the past; this can safely be ignored.
Set up a Personal Access Token
Warning
If the file ~/.config/bloom
exists on your computer, it is likely that you have done this before so you should skip this section.
During the release process, multiple HTTPS Git operations will be performed that require password authentication. To avoid being repeatedly asked for a password, a Personal Access Token (PAT) will be set up. If you have multi-factor authentication setup on your GitHub account, you must setup a Personal Access Token.
Create a Personal Access Token by:
Log in to GitHub and go to Personal access tokens.
Click the Generate new token button.
In the dropdown, select Generate new token (classic)
Set Note to something like
Bloom token
.Set Expiration to No expiration.
Tick the
public_repo
andworkflow
checkboxes.Click the Generate token button.
After you have created the token, you will end up back at the Personal access tokens page. Copy the alphanumeric token that is highlighted in green.
Save your GitHub username and PAT to a new file called ~/.config/bloom
, with the format below:
{
"github_user": "<your-github-username>",
"oauth_token": "<token-you-created-for-bloom>"
}
Ensure repositories are up-to-date
Make sure that:
Your repository is hosted on a remote such as GitHub.
You have a clone of the repository on your computer and are on the right branch.
Both the remote repository and your clone are up-to-date.
Updating Changelog
For your users and for the developers, keep the changelog concise and up to date.
catkin_generate_changelog
Open all CHANGELOG.rst
files in an editor.
You will see that catkin_generate_changelog
has auto-generated a forthcoming section with notes from commit messages:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Changelog for package your_package
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Forthcoming
-----------
* you can modify this commit message
* and this
Clean up the list of commit messages to concisely convey the notable changes that have been made to the packages since the last release, and commit all the CHANGELOG.rst files.
Do not modify the Forthcoming
header.
Bump the package version
Every release of the package must have a unique version number higher than the previous release. Run:
catkin_prepare_release
which performs the following:
increases the package version in
package.xml
replaces the heading
Forthcoming
withversion (date)
(eg.0.0.1 (2022-01-08)
) inCHANGELOG.rst
commits those changes
creates a tag (eg.
0.0.1
)pushes the changes and the tag to your remote repository
Note
By default the patch version of the package is incremented, such as from 0.0.0
to 0.0.1
.
To increment the minor or major version instead, run catkin_prepare_release --bump minor
or catkin_prepare_release --bump major
.
For more details, see catkin_prepare_release --help
.
Bloom Release
Run the following command, replacing my_repo
with the name of your repository with the packages:
bloom-release --rosdistro iron my_repo
Bloom will automatically create a pull request for you against rosdistro.
Next Steps
Once your pull request has been submitted, usually within one or two days, one of the maintainers of rosdistro will review and merge your Pull Request. If your package build is successful, in 24-48 hours your packages will become available in the ros-testing repository, where you can test your pre-release binaries.
Approximately every two to four weeks, the distribution’s release manager manually synchronizes the contents of ros-testing into the main ROS repository. This is when your packages actually become available to the rest of the ROS community. To get updates on when the next synchronization (sync) is coming, subscribe to the Packaging and Release Management Category on ROS Discourse.