Revision history [back]

The precipitation of this change was well covered by @jbohren

We are currently in the process of rolling out this change, unfortunately catkin hitting the public repositories was the first thing that had to happen, and it happened on a weekend.

I have just updated the wiki:

http://ros.org/wiki/catkin/package.xml#Metapackages

I am going to release bloom 0.3.3 (which also has changes related to this), republish the REP pages, regenerate the catkin documentation, and then send an email about the change.

As for why this is in groovy? It is not an API breaking change, it does nothing more than warn you if you are building a non compliant metapackage locally. The only case where it breaks is if you have a random CMakeLists.txt wandering around in the root of your metapackages, which is not correct anyways. On the flip side, releasing it into groovy prevents us from having yet further special case handling in tools like catkin_pkg and bloom.

As for documentation of catkin_metapackage, it is self documented:

https://github.com/ros/catkin/blob/groovy-devel/cmake/catkin_metapackage.cmake#L1

And those docs will be in the generated documentation for catkin, which will also be regenerated today as we roll this out.

The precipitation of this change was well covered by @jbohren

We are currently in the process of rolling out this change, unfortunately catkin hitting the public repositories was the first thing that had to happen, and it happened on a weekend.

I have just updated the wiki:

http://ros.org/wiki/catkin/package.xml#Metapackages

I am going to release bloom 0.3.3 (which also has changes related to this), republish the REP pages, regenerate the catkin documentation, and then send an email about the change.

As for why this is in groovy? It is not an API breaking change, it does nothing more than warn you if you are building a non compliant metapackage locally. The only case where it breaks is if you have a random CMakeLists.txt wandering around in the root of your metapackages, which is not correct anyways. On the flip side, releasing it into groovy prevents us from having yet further special case handling in tools like catkin_pkg and bloom.

As for documentation of catkin_metapackage, it is self documented:

https://github.com/ros/catkin/blob/groovy-devel/cmake/catkin_metapackage.cmake#L1

And those docs will be in the generated documentation for catkin, which will also be regenerated today as we roll this out.

The precipitation of this change was well covered by @jbohren

We are currently in the process of rolling out this change, unfortunately catkin hitting the public repositories was the first thing that had to happen, and it happened on a weekend.

I have just updated the wiki:

http://ros.org/wiki/catkin/package.xml#Metapackages

I am going to release bloom 0.3.3 (which also has changes related to this), republish the REP pages, regenerate the catkin documentation, and then send an email about the change.

As for why this is in groovy? It is not an API breaking change, it does nothing more than warn you if you are building a non compliant metapackage locally. The only case where it breaks is if you have a random CMakeLists.txt wandering around in the root of your metapackages, which is not correct anyways. On the flip side, releasing it into groovy prevents us from having yet further special case handling in tools like catkin_pkg and bloom.

As for documentation of catkin_metapackage, it is self documented:

https://github.com/ros/catkin/blob/groovy-devel/cmake/catkin_metapackage.cmake#L1

And those docs will be in the generated documentation for catkin, which will also be regenerated today as we roll this out.

UPDATE: UPDATE:

• catkin's RST docs have been updated and will be regenerated tonight (this happens nightly)

• bloom 0.3.3 has been released
• hosted REP pages have been updated
• email has been sent