The buildfarm lists Lyrical, the branch policy does not

main breaks APIs and blooms to one distro, the rest do not

The branch policy table is the most operationally important thing on the front page, and it is unusually explicit. The main branch is for development, carries breaking changes, targets all active distributions in a distro-portable way, and is bloomed to the buildfarm only on Rolling. The humble, jazzy and kilted branches are stable, take no breaking changes beyond backported bug fixes, target exactly one distribution each, and are bloomed to exactly one distribution each. In practice that means development against main is a moving target that will break your configuration code, while a named distro branch is where you do production work. The README also links a development roadmap and a page of future release dates, so the schedule is published rather than inferred, and a MoveIt 2 migration guidelines document plus a migration progress spreadsheet are linked from the same list.

The buildfarm table names a distro the branch policy omits

The buildfarm section is a matrix of binary build jobs, with packages as rows and distributions as columns. The rows are the ROS packages MoveIt ships: geometric_shapes, osqp_vendor, moveit, moveit_common, moveit_configs_utils and more. The columns are Rolling Binary, Lyrical Binary, Jazzy Binary and Humble Binary, with a job link per cell so you can see the actual build. Lyrical is the interesting entry, because the branch policy lists humble, jazzy and kilted and does not mention Lyrical at all. So the two tables describe the project from different angles, and the buildfarm is telling you that binaries exist for a distribution the policy table does not name. That is not necessarily a contradiction, since a column can exist for a branch whose name the policy omits, but it does mean you cannot rely on the branch table alone to enumerate what you can install, and you should check the buildfarm for your distribution before planning a binary install.

This is a port, and the migration guide is in the repository

MoveIt 2 is the ROS 2 version of a framework that began as MoveIt 1, and the repository is explicit about the lineage. The ROS 1 repository is a separate project at moveit/moveit, and for the commercially supported version the README points at MoveIt Pro from PickNik. Inside this repository, both MIGRATION.md at the root and doc/MIGRATION_GUIDE.md are named in the links, plus an external migration progress spreadsheet. For a team coming from MoveIt 1, those documents are the actual work: a port means the APIs a robot application calls changed, and the framework's own repository is where that change is documented. That MIGRATION.md sits beside README.md rather than in a wiki is itself a useful signal, since the migration story is versioned with the code and travels with a checkout rather than living somewhere that can change under you.

A vendor leads the project and sells the supported version

The support section says the project is maintained by supporters from around the world and links a maintainers and core contributors page, then names PickNik Inc as the company leading the development of MoveIt, with a contact address for supporting the work. The port to ROS 2 was funded separately: ROSIN, ROS-Industrial Quality-Assured Robot Software Components, supported it, and the project received European Union Horizon 2020 research and innovation programme funding under grant agreement number 732287. So the governance is a mix of commercial sponsorship and public grant money on top of an open source BSD codebase. The practical consequence for anyone evaluating this is a fork in the road: the free project gives you the framework and the branches, while MoveIt Pro is the commercially supported version from the same vendor, and the two are separate products with separate terms.

The repository is a dozen packages, not one library

That top-level layout is the clearest description of what MoveIt 2 actually is. There is moveit/ and moveit_common/ and moveit_core/, then moveit_kinematics/ for kinematics, moveit_planners/ for the planners themselves, moveit_plugins/ for the pluggable pieces, moveit_py/ which is the Python binding layer, moveit_ros/ for the ROS integration, moveit_runtime/, and moveit_setup_assistant/ which is the configuration assistant. Two utility packages sit alongside: moveit_configs_utils/ and a shared geometric_shapes concept that also appears in the buildfarm rows. That package split matters practically because a consumer does not necessarily take all of it, and because the Python layer is its own package rather than an afterthought. There are also two workspace descriptor files at the root, moveit2.repos and moveit2_rolling.repos, which is the usual way ROS 2 projects distribute the full set of dependencies for a source build.

Install is a choice of binary or source, both documented elsewhere

The README keeps installation short by linking two pages rather than embedding commands: a binary install page and a source build page, both on moveit.ai. The binary path is the practical one for most teams, since the buildfarm matrix shows which packages have published artifacts for which distributions, and a per-distribution branch exists for the distro you target. The source path is what you use when you need a branch that has not been bloomed, when you need main, or when you are contributing. Documentation itself is not in this repository either: tutorials and documentation are at moveit.picknik.ai, API Doxygen reference is generated locally following a how-to guide, and the repository holds a Doxyfile plus a sonar-project.properties file that show both are configured here even though the output is published elsewhere. Continuity and contribution guidance sit in the repository as CODE_OF_CONDUCT.md, CONTRIBUTING.md and a .pre-commit-config.yaml.

Where MoveIt 2 is the wrong tool

Four cases. The first is ROS 1. The framework for that is MoveIt 1 in a different repository, and using this one means a port, not a package swap. The second is a team that needs vendor support without paying for it. PickNik leads development and sells MoveIt Pro as the commercially supported version, so an unsupported deployment of the free project means your fallback when a planning bug appears is the issue tracker and the migration guide. The third is a production system that tracks main. The branch policy says main carries breaking changes, so a robot that plans correctly this week can stop planning after an update, and the mitigation is choosing a distro branch and budgeting for backported bug fixes only. The fourth is a project with no ROS dependency at all. This is a ROS 2 framework distributed as ROS 2 packages with a .repos workspace descriptor and buildfarm binaries per distribution, so if your manipulation code does not already speak ROS 2, adopting it means adopting ROS 2 first, which is the larger decision.

Editorial conclusion

MoveIt 2 suits a robotics team already on ROS 2 that needs manipulation planning, collision checking and maintained per-distribution branches rather than a single moving target. It does not suit a ROS 1 codebase, which needs MoveIt 1 in a different repository, nor a team that needs vendor support without buying MoveIt Pro. Before adopting, pick a distro branch rather than main, check the buildfarm matrix for binary packages on your distribution, and read doc/MIGRATION_GUIDE.md to see which MoveIt 1 APIs change.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. moveit/moveit2 on GitHub
4. Project website
5. README