MoveIt has a 6 week cadence for releases, though we occationally miss this schedule. We are working to better automate this process.
This 6 week pace is a balance between releasing new improvements quickly and preserving the stability of releases. We are choosing this schedule to reduce the amount of work per release, reduce the time it takes to get an improvement released and make it easier to schedule for the Picknik team. These releases will include the main MoveIt repo along with any dependencies we control if they have changed (e.g. moveit_msgs).
The release schedule is shown here:
The maintainer handling the release must have write access to both devel repos (e.g. github.com/ros-planning/moveit) as well as release repos (e.g. github.com/ros-gbp/moveit-release). The release repo access is managed via the Github Team moveit-maintainers.
reviewed-for-backportbranch exists as a marker in the commit history for
master, marking the last commit that was considered for backporting. Run
git cherry -v <release-branch> master reviewed-for-backport | grep '^+'to generate a list of all commits between
reviewed-for-backportand the current
masterbranch that have not been merged in
release-branch(without modifications). Backports should be pull-requests and reviewed separately, though possibly bundled.
Default for Kinetic-Xenial where the
HEAD at the moveit repo is what we want to release, and Kinetic-Wily (basically the same except for the Ubuntu distro type):
_DIR_PRLTEST=/tmp/prerelease_job_kin-xen; mkdir -p $_DIR_PRLTEST && cd $_DIR_PRLTEST generate_prerelease_script.py https://raw.githubusercontent.com/ros-infrastructure/ros_buildfarm_config/production/index.yaml melodic default ubuntu xenial amd64 moveit --level 0 --output-dir ./ generate_prerelease_script.py https://raw.githubusercontent.com/ros-infrastructure/ros_buildfarm_config/production/index.yaml melodic default ubuntu wily amd64 moveit --level 0 --output-dir ./
Update changelogs. Take advantage of
catkin_generate_changelog command to populate new logs, then preferably edit them manually to cleanup/combine changelog messages and mark/sort them by type of change (e.g. bugfix, feature, maintenance, documentation). Have a look at previous changelogs to get an idea of the verbosity level and formatting. Example of the whole command set:
cd moveit (Top directory of your cloned moveit repo.) git checkout master git log (Make sure the HEAD is what you want to release with. If it's not then update accordingly.) catkin_generate_changelog emacs `find . -iname CHANGELOG.rst` (Edit each file. Emacs forever, but replace it if necessary :/) git add `find . -iname CHANGELOG.rst` (Stage all changelogs)
Figure out the correct next version number (see the version policy section below) and utilize the command
catkin_prepare_release that adapts the version numbers in all package.xml and changelog files, creates a new tag, and eventually pushes to the remote repo (you can check at github.com/ros-planning/moveit/releases). Example command:
(Assuming you're at the same directory as before.) catkin_prepare_release --version x.x.x (Replace x.x.x with the correct version number!)
bloom-release --rosdistro melodic moveit
# Bump the release number, but don't yet push to github catkin_prepare_release --no-push # Reword the commit message generated by `catkin_prepare_release` from `x.x.x` to: git commit --amend -m "Bump version to x.x.x" # Remove created version tag (which must not pushed to github) git tag -d x.x.x # Push to github repo (or file a pull request) git push origin
<release-branch>: git checkout reviewed-for-backport; git merge --ff-only <release-branch>.
HEADof a development branch will already indicate the next upcoming release version. See rational.
# MoveIt <ROS_VERSION_NAME> Release (<VERSION>) [_moveit.ros.org release documentation_](/documentation/contributing/releases/) ### Backports - [ ] . - [ ] . ### Checklist - [ ] Merge backports - [ ] Run ROS buildfarm prerelease test - [ ] Update changelogs - [ ] Bloom - [ ] Write discourse post