ROS Noetic End-of-Life: May 31, 2025

sloretz · 2025-04-10T20:48:56.134Z

Hello ROS Noetic users and maintainers!

This week the ROS PMC formally voted to set the Noetic end-of-life (EOL) date to May 31, 2025. This is the same day Ubuntu Focal reaches end of standard support.

I’m a ROS Noetic user, what do I need to know?

You need to know that it is time to upgrade! 80% of the ROS community has already made the switch.

We put together a single page of guidance for current ROS Noetic users who need to upgrade to ROS 2: ROS: Upcoming ROS 1 End of Life

I’m a ROS Noetic maintainer

How long do I have to make releases?

If you maintain a ROS Noetic repository and you haven’t made a release in a while, then you should make a release now.

There are only a few syncs left. The last two syncs will follow this schedule:

May 13th:
- A ros/rosdistro freeze for the second to last sync begins
- You must bloom-release your package before this date to guarantee it is included in the second to last sync
May 15th:
- The second to last sync is performed [1]
May 16th:
- A freeze for the last sync begins
- You must bloom-release your package before this date to guarantee it is included in the last sync
May 16th through May 29th:
- ros/rosdistro PRs will only be merged if they fix regressions
- ros/rosdistro PRs adding new features will not be merged
- ros/rosdistro PRs adding new packages will not be merged
May 29th
- The last sync is performed [1]
- No new ROS Noetic ros/rosdistro PRs will be accepted
May 31st - ROS Noetic is marked EOL

[1] The sync dates may be delayed if releases cause regressions that need to be resolved or rolled back.

What should maintainers do to prepare for EOL?

First, if you have unreleased changes, then make a release now.

There won’t be an opportunity to fix regressions in binary packages once ROS Noetic goes EOL, so consider reducing the risk of regressions when reviewing PRs by:

Closing all pull requests breaking API or ABI
Closing all pull requests adding new features
Asking bug fix PR authors to recruit multiple reviewers to test it

Some users will build ROS Noetic from source, for example, to use the ros1_bridge. Consider merging PRs that make your package build on newer Ubuntu versions.

If your repository only supports ROS 1, and you are not going to maintain it after ROS Noetic goes EOL, then make that clear to your users on May 31, 2025 by:

Closing open PRs and issues
Archiving the repo

If your repository supports ROS 1 and ROS 2, then make sure the default branch supports ROS 2, preferably ROS Rolling.

Katherine_Scott · 2025-04-10T20:50:13.411Z

peci1 · 2025-04-10T21:19:25.479Z

sloretz:

Consider merging PRs that make your package build on newer Ubuntu versions

Is there a list of changes that are known to affect most packages and would be easy to do to help future-proofing Noetic packages? E.g. increasing CMake min version to some specific number, ifdefing for some boost novelties or something similar?

sloretz · 2025-04-10T21:44:17.952Z

I’m not aware of a list, but here’s a few examples I’ve seen in multiple repositories:

Removing use of boost::placeholders
Using setuptools instead of distutils (except for the Python 2 support in the package.xml)
Unspecifying the C++ version so the compiler can use a newer one
Bump CMake version to at least 3.5 (But not higher than 3.13.4)

peci1 · 2025-04-10T22:13:26.929Z

sloretz:

Unspecifying the C++ version so the compiler can use a newer one

Hmm, @mikeferguson suggests something a bit different than just removing the C++ standard flag

# Default to C++17
if(NOT CMAKE_CXX_STANDARD)
  set(CMAKE_CXX_STANDARD 17)
endif()

Is one or the other preferred?

sloretz:

Bump CMake version to at least 3.5

I usually use 3.10.2 as that is the version that still works with Melodic and is relatively modern at the same time.

sloretz · 2025-04-10T22:24:46.723Z

peci1:

Hmm, @mikeferguson suggests something a bit different than just removing the C++ standard flag
# Default to C++17
if(NOT CMAKE_CXX_STANDARD)
  set(CMAKE_CXX_STANDARD 17)
endif()
Is one or the other preferred?

If I understand correctly, the important part is not setting the standard too low. If it’s too low then headers included from some dependencies might not build with that standard. Officially ROS Noetic targets C++14, so I’d recommend any solution that uses C++14 by default. I’d probably recommend target_compile_features(target PUBLIC cxx_std_14), but I also haven’t tried that in ROS Noetic (docs)

v4hn · 2025-04-11T08:06:27.158Z

Thank you a lot for the structured approach and good communication @sloretz .
It’s by far the most impactful end-of-distribution action for an OpenRobotics’s based software distribution so the clear structure is very much appreciated!

sloretz:

If I understand correctly, the important part is not setting the standard too low. If it’s too low then headers included from some dependencies might not build with that standard. […] so I’d recommend any solution that uses C++14 by default.

The reason is correct but the conclusion is wrong.
I urge maintainers to leave the C++ standard unspecified in the build system and remove existing definitions.
A big part of patches pushed in the ROS-O repositories are to ensure code will still compile when log4cxx started requiring c++17 - various other dependencies following through later.
There is no reason to require C++14 explicitly because it is already the compiler default in Ubuntu 20.04. Specifying C++17 might seem better - but that just means everything breaks again when libraries expose concept definitions and require C++20.
The if(NOT CMAKE_CXX_STANDARD) approach quoted above is possible, but it still means that things will break for every single person trying to build the defaults because they have to specify the standard when building their workspace.

peci1 · 2025-04-11T08:47:22.714Z

Hmm, but what if our code internally requires C++17? I always understood that the policy was to keep public APIs C++14 only, while C++17 was allowed in implementations. How should that be tackled then? Is there something like CMAKE_CXX_MINIMUM_STANDARD?

v4hn · 2025-04-12T12:24:32.780Z

peci1:

Hmm, but what if our code internally requires C++17? I always understood that the policy was to keep public APIs C++14 only, while C++17 was allowed in implementations. How should that be tackled then?

That is definitely the case for a lot of your work, true. My post targeted the majority of cases where c++11 or 14 was unnecessarily stated in packages that explicitly target Ubuntu 20.04 upwards.
When you use c++17 but explicitly support Ubuntu 20.04, you should use the if(NOT CMAKE_CXX_STANDARD) construct. MoveIt refines it a bit and only adds the flag for g++/clang when they are too old.

That being said, it is a simple option to add a new ros1, roso, obese branch to your repo with almost no overhead or continue using an existing master/main branch and drop support for Ubuntu 20.04 there. If you do not plan to actively port features there, it’s a one-liner in the README to tell your users and it still makes it easier for users to compile your existing code in the future because you can adapt trivial patches. Otherwise, assuming the package is relevant to the ROS-O community, it will sooner or later end up as a fork in the ros-o github organization.

Katherine_Scott · 2025-04-24T18:13:19.268Z