ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

What does ROS distro "freeze" require?

asked 2013-07-08 11:50:03 -0500

130s gravatar image

updated 2013-07-09 00:29:43 -0500

What does ROS distro freeze mean? Is there anything required for developers and users?

Since I thought it's general idea in (opensource) development, I Googled but with no success. Only links that show exhaustive answer is sufficient.

I found in a conversation among ros_controlers that someone says API should be locked down. That makes sense but I just want a complete answer to this question.

Update) Thanks to @fergs and @joq now I'm more understood the importance of stabilizing API per freeze. I forgot to mention that one of my primary concerns was if there's also practice/rule about new release of package after freeze (my guess is that we can release new pkgs anytime as long as api stays stable, knowing adding new classes and functions are allowed in ABI Compatibility Req).

edit retag flag offensive close merge delete



New packages should be OK, since presumably nothing else depends on them yet.

joq gravatar image joq  ( 2013-07-12 05:42:19 -0500 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2013-07-08 14:47:28 -0500

joq gravatar image

updated 2013-07-09 06:26:54 -0500

In practice, a "freeze" means that core ROS components may not make any more API changes for that release.

There may still be bug fixes, but they should not disrupt the higher-level packages that depend on them.

Update: "Freeze" is mainly a system integration concept, commonly used by Linux distros, and not usually required at the level of a single open source package.

ROS releases many packages, and must provide a scaled-down version of the system integration requirements of a full Linux distro. In former releases we had concepts of "first-freeze" (for low-level interfaces) and "final-freeze" (for everything in the release).

Once an API is frozen, it should not change until the following distro. Sometimes exceptions are made, occasionally for good reasons, but usually because some developer did not understand the burdens of system integration.

edit flag offensive delete link more

answered 2013-07-08 14:15:51 -0500

fergs gravatar image

Some of these have not been updated for the new catkin style packages/metapackages, but there is the Stack Version Policy on the wiki. There are couple of guidelines here that are pretty prevalent in ROS:

  • After 0.4.0, the API should generally try to be stable (although, understandably it may not).
  • After reaching a 1.0 level stacks released into distros are expected to be stable within a release

Additionally, for 1.0 and above, REP9 discusses ABI compatibility within a release. Unfortunately, this part is not well followed.

This brings us to "within a release" -- once the beta has been announced, you should not break the API for >1.0, and hopefully not for >0.4.0 releases, it should really only be bugfixes from beta time to "release". Hopefully, you also avoid breaking the ABI, but this is rarely caught anyways, since the buildfarm currently rebuilds all downstream projects when you release.

None of this is really enforced by some sort of build farm test or rosdistro test or whatnot that tells you "no, don't release this into X, release into distro X+1", you as a developer have to be diligent with what you release -- if not, it can cause major headaches downstream. For instance, long after the beta ended, Groovy RVIZ changed how it dealt with DAE file scaling, which meant that a number of robot packages became broken as they had been hacked to work with the older, not quite proper, scaling. Yes, it made sense to fix this, but should not have been released into Groovy. Due to the staging involved in getting a new set of freshly built packages out the door, this meant that for about 2+ weeks, anyone installing TurtleBot from fresh packages had a completely broken visualization. We've also recently had issues when packages were catkinized mid-way through the life cycle of a distribution.

TLDR: don't change things without thinking, there isn't a lot of infrastructure to tell you when you are about to break the world.

edit flag offensive delete link more


It's good to be reminded about package versioning policy although it's outdated (assuming in the near future it will get tailored for catkin and 2.0?).

130s gravatar image 130s  ( 2013-07-09 00:20:21 -0500 )edit

Question Tools


Asked: 2013-07-08 11:50:03 -0500

Seen: 344 times

Last updated: Jul 09 '13