--upstream option broken for custom upstream tags

[mikepurvis]

Example:

$ rosinstall_generator geographic_info --rosdistro indigo
- git:
    local-name: geographic_info/geographic_info
    uri: https://github.com/ros-geographic-info/geographic_info-release.git
    version: release/indigo/geographic_info/0.4.0-0

$ rosinstall_generator geographic_info --rosdistro indigo --upstream-development
- git:
    local-name: geographic_info
    uri: https://github.com/ros-geographic-info/geographic_info.git
    version: master

$ rosinstall_generator geographic_info --rosdistro indigo --upstream
- git:
    local-name: geographic_info
    uri: https://github.com/ros-geographic-info/geographic_info.git
    version: 0.4.0

The final one is broken— the actual tag is https://github.com/ros-geographic-info/geographic_info/releases/tag/geographic_info-0.4.0, but rosinstall_generator has no way of knowing this without additional data from the GBP repo.

[wjwwood]

Yeah, that particular setting never really made sense to me, because ideally it is exactly the same as the release repository's tag. In practice there can be patches which are applied in the release repository and you might want "upstream"'s version of the release without the patches, but I have a hard time imagining a case where that's useful.

It's problematic to capture this information without getting it from the release repository. You could have an "upstream_url" and "upstream_tag" in the "release" section of the distribution file on ros/rosdistro, but that would only tell you about the latest release, i.e. the tag structure could change from one release to the next. So you really need an "upstream_url"/"upstream_tag" pair for each release.

I'm not sure it's worth trying to fix this particular option, and maybe we should just have it tell you (in stderr or in documentation) that it is a best guess sort of thing. The released version and the --upstream-source options will always be right so long as the contributors put the right information into the distribution file on ros/rosdistro.

[mikepurvis]

This problem gets even worse if if someone uses the :{ask} option for bloom's Release Tag, since then it's totally free-form— you can even put a sha1 in there and bloom will go ahead and release from the reference while leaving no record at all behind of what source version led to it.

[mikaelarguedas]

+1: I faced the same issue recently, trying to fetch the code of ROS Bouncy I ended up with non existing tags for third party repositories that are released with a commit hash as a release tag.

Not a blocker for my use case, mostly commenting here so that we know it is currently a problem user will face in mainline ROS 2 if they use the --upstream flag.