diff --git a/about/distribution/index.markdown b/about/distribution/index.markdown index f2751ad8..be56a62c 100644 --- a/about/distribution/index.markdown +++ b/about/distribution/index.markdown @@ -37,12 +37,6 @@ title: Distribution MoveIt 2 Iron May 2029 - - MoveIt 2 Iron - May 23, 2023 - MoveIt 2 Iron - November 2024 - MoveIt 2 Humble May 23rd, 2022 @@ -55,12 +49,6 @@ title: Distribution MoveIt 1 Noetic May 2025 - - MoveIt 1 Melodic - June 5th, 2020 - MoveIt 1 Melodic - May 2023 -

Distribution Details

diff --git a/documentation/contributing/maintainer_pr/index.markdown b/documentation/contributing/maintainer_pr/index.markdown index c216e975..984b2ea3 100644 --- a/documentation/contributing/maintainer_pr/index.markdown +++ b/documentation/contributing/maintainer_pr/index.markdown @@ -13,7 +13,7 @@ To ease the process of getting contributions merged into the project quickly, th ## Branches Policy -Our development branches are called ``main`` (MoveIt 2) and ``master`` (MoveIt 1). We also have important distribution-specific release branches, named ``*-devel`` (MoveIt 1) or just e.g. ``foxy`` (MoveIt 2). +Our development branches are called ``main`` (MoveIt 2) and ``master`` (MoveIt 1). We also have important distribution-specific release branches, named ``*-devel`` (MoveIt 1) or just e.g. ``jazzy`` (MoveIt 2). ## No Direct Commits or Force Pushes @@ -74,7 +74,7 @@ Future versions of MoveIt might not share the whole history of older branches an Don't merge a request unless you make sure the same (or a similar) patch-set is merged into all later branches at the same time. We don't want to lose changes that are available in one ROS distribution because someone forgot to do that. -We use [`mergify`](https://docs.mergify.com) to automize backporting. Just add the corresponding label, e.g. `backport-foxy` to trigger a backport to Foxy. +We use [`mergify`](https://docs.mergify.com) to automize backporting. Just add the corresponding label, e.g. `backport-jazzy` to trigger a backport to Jazzy. If the commits apply cleanly to future branches and there is no evidence that they will break anything there, you are free to add the changes to the respective branches. (Make sure you respect the all-commits-in-latest-branch guideline though). diff --git a/documentation/contributing/releases/index.markdown b/documentation/contributing/releases/index.markdown index 0f3feaa1..77a5e66a 100644 --- a/documentation/contributing/releases/index.markdown +++ b/documentation/contributing/releases/index.markdown @@ -7,13 +7,11 @@ title: Releases # Release Process -MoveIt has a 6 week cadence for releases, though we occasionally miss this schedule. We are working to better automate this process. +While the latest code is always available in source format, we also make releases available in binary formats. Releases are made on a periodic basis into all of the currently supported ROS distributions. The decision to make a new release is usually made during the monthly maintainer meeting. -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). +New features and API or ABI breaking changes can be merged at any time into the `main` branch. For this reason, most ROS releases will have a stable branch named after the ROS release, for instance `jazzy`. These release-specific branches aim to maintain API and ABI compatibility for the life of the ROS distribution. -## Upcoming releases - -Releases for MoveIt are planned using the ZenHub Roadmap. You can follow our [detailed Roadmap here](https://app.zenhub.com/workspaces/moveit-61675936b391800012280f6d/roadmap). +Since it usually takes some time for users to migrate to a new ROS distribution, these release-specific branches are usually not forked from `main` until approximately six months after the official release of the ROS distribution is made (recent ROS releases have been made in May, so this usually happens in November). The official decision to fork is usually made during a maintainer meeting. ## Permissions @@ -21,7 +19,7 @@ The maintainer handling the release must have write access to both devel repos ( ## Steps -1. Create an issue to track the status of the upcoming release. This issue should include a list of the changes since the last release so maintainers can determine which ones should be backported into the release branch. Do this for each repo that will be released with references to the issue in the main repo. To generate the list of changes use the `review-for-backport` branch. The `reviewed-for-backport` branch exists as a marker in the commit history for `master`, marking the last commit that was considered for backporting. Run `git cherry -v master reviewed-for-backport | grep '^+'` to generate a list of all commits between `reviewed-for-backport` and the current `master` branch that have not been merged in `release-branch` (without modifications). Backports should be pull-requests and reviewed separately, though possibly bundled. +1. Create an issue to track the status of the upcoming release. This issue should include a list of the changes since the last release so maintainers can determine which ones should be backported into the release branch. Do this for each repo that will be released with references to the issue in the main repo. To generate the list of changes use the `review-for-backport` branch. The `reviewed-for-backport` branch exists as a marker in the commit history for `main`, marking the last commit that was considered for backporting. Run `git cherry -v main reviewed-for-backport | grep '^+'` to generate a list of all commits between `reviewed-for-backport` and the current `main` branch that have not been merged in `release-branch` (without modifications). Backports should be pull-requests and reviewed separately, though possibly bundled. 1. Run ROS buildfarm prerelease test for **all** supported Ubuntu distributions in [REP-0003](http://www.ros.org/reps/rep-0003.html). * You can see [here](http://wiki.ros.org/bloom/Tutorials/PrereleaseTest) for the general instruction of prerelease test. If you're done for the setup already and just want to refer to command examples, see [here](http://wiki.ros.org/regression_tests#Running_prerelease_test). * As long as REP-0003 supports, we must test even EOLed Ubuntu distros (e.g. Saucy for ROS Indigo was retired in 2014 but REP-0003 still supports it and there's no way as of December 2016 to skip it. See [moveit/#100](https://github.com/moveit/moveit/issues/100#issuecomment-268826497) as a previous example). @@ -73,7 +71,7 @@ The maintainer handling the release must have write access to both devel repos ( find . -iname package.xml -exec \ sed -i "s#.*#x.y.z#g" {} \; ``` -1. Write release notes on moveit.ros.org (e.g. [1](https://github.com/moveit/moveit.ros.org/pull/115), [2](https://github.com/moveit/moveit.ros.org/pull/110)). Send it to [Discourse MoveIt category](https://discourse.ros.org/c/moveit). +1. Write release notes on moveit.ai (e.g. [1](https://github.com/moveit/moveit.ros.org/pull/115), [2](https://github.com/moveit/moveit.ros.org/pull/110)). Send it to [Discourse MoveIt category](https://discourse.ros.org/c/moveit). 1. Forward the `reviewed-for-backport` branch to `: git checkout reviewed-for-backport; git merge --ff-only `. ### Release Versioning Policy