add new CMake function catkin_download_test_data #431
Conversation
|
The new interface looks good, Dirk. I'll test it as soon as I find time. |
…data as deprecated
|
reviewed +1 |
add new CMake function catkin_download_test_data
|
It would be extremely helpful to know when something like this is actually released, so I can change my own tests to depend on it. |
|
This is what the changelog files are for. The maintainer can either give an expected date for the forthcoming section in there or use external infrastructure like milestones. This particular change will be released either today or tomorrow (plus the time it takes to rebuilding everything plus time until it get synced). |
|
How does the change log cause me to be notified that the release happened? |
|
The maintainer can provide the information in the forthcoming section, e.g. "expected to be released around mid June". Or he can create a milestone "next release" with a due date. If that is not the case you can only track the ros/rosdistro/DISTRO/release.yaml file for changes or wait for the announcement from Tully once the packages have been synced. |
|
That is polling, rather than notification. Why not just leave the issue open until the fix is released? |
|
It is common procedure to close issues when the fix gets applied to the source repo. Closing issues when they are available in public is even more cumbersome, since a) multiple distros might have very different sync times and b) the person performing the sync does not even have the necessary information to close all affected issues in the upstream repos. The closest I could imaging would be an rss feed on when a specific package changes in a given distro but someone would need to write a web service like this. |
|
Closing at the time of release would be good enough. Once it's released, other things that depend on it can be pre-release tested and then released themselves. That can be done via github references to the issues fixed. The change log should contain all those references, anyway, so it's easily done. |
|
Just for the record: the merge with the hash above does not appear in the groovy-devel branch (looks like i screwed up the merge somehow). It is now merged in 1480bf7. |
|
The new command does not appear on the extracted CMake API reference page: |
|
Seems to work: |
Refactor a bit for readability.
mark download_test_data as deprecated.
Based on the discussion in #426 I have added a new download function with the necessary API to use it in any way suggested in there. It also exposes the target name explicitly (as any other CMake function) to enable the user land code to add custom dependencies.