cob_common: 0.7.11-1 in 'noetic/distribution.yaml' [bloom]

[fmessmer]

Increasing version of package(s) in repository cob_common to 0.7.11-1:

• upstream repository: https://github.com/4am-robotics/cob_common.git
• release repository: https://github.com/4am-robotics/cob_common-release.git
• distro file: noetic/distribution.yaml
• bloom version: 0.12.0
• previous version for package: 0.7.10-1

cob_actions

• No changes

cob_common

* Merge pull request #308 <https://github.com/4am-robotics/cob_common/issues/308> from fmessmer/noetic-devel
  [ROS1] cob4 eol cleanup
* remove cob_description
* remove raw_description
* Contributors: Felix Messmer, fmessmer

cob_msgs

• No changes

cob_srvs

• No changes

[sloretz]

I think this does what you intend, but it's complicated enough that I'll ask for a second reviewer.

[clalancette]

It is uncommon for the doc version and the source version to be different. It isn't strictly disallowed, but can you explain why these are different?

[fmessmer]

@quarkytale @clalancette
the PR is marked "changes requested" - however, please see my #40670 (comment)
How would you like to proceed here and what do you want me to change?

[clalancette]

Sorry for the long delay in getting back to you here. What this PR is doing is very complicated, and hard to follow.

In particular, while I understand that you are splitting this up, I'm also not sure how this is going to practically work for doing releases. Since we are using the same source repository and the same release repository for cob_common and cob_common_legacy, how is a bloom-release on either of them supposed to work here? If you do bloom-release cob_common, then it will release cob_actions, cob_common, cob_msgs, and cob_srvs to the new version (let's call it 0.7.12). If you then do bloom-release cob_common_legacy, it will release cob_actions, cob_common, cob_description, cob_msgs, cob_srvs, and raw_description. But that is duplicating what was done above, so this will always be out-of-sync.

Can you maybe explain how you intend to make this work?

[fmessmer]

Sorry for the long delay in getting back to you here. What this PR is doing is very complicated, and hard to follow.

In particular, while I understand that you are splitting this up, I'm also not sure how this is going to practically work for doing releases. Since we are using the same source repository and the same release repository for cob_common and cob_common_legacy, how is a bloom-release on either of them supposed to work here? If you do bloom-release cob_common, then it will release cob_actions, cob_common, cob_msgs, and cob_srvs to the new version (let's call it 0.7.12). If you then do bloom-release cob_common_legacy, it will release cob_actions, cob_common, cob_description, cob_msgs, cob_srvs, and raw_description. But that is duplicating what was done above, so this will always be out-of-sync.

Can you maybe explain how you intend to make this work?

I only intend to continue supporting bloom-release cob_common (i.e. for cob_actions, cob_common, cob_msgs and cob_srvs), i.e. updating the rosdistro entry for cob_common
I do not intend to edit the rosdistro entry for cob_common_legacy at all anymore (maybe except for the "doc vs. source" consistency change) - other than that, cob_common_legacy has not been released via bloom-release - I manually added this key...there will also not be any bloom-release cob_common_legacy in the future - I just want to keep the debian packages available in the pinned (legacy) version

[clalancette]

I only intend to continue supporting bloom-release cob_common (i.e. for cob_actions, cob_common, cob_msgs and cob_srvs), i.e. updating the rosdistro entry for cob_common I do not intend to edit the rosdistro entry for cob_common_legacy at all anymore (maybe except for the "doc vs. source" consistency change) - other than that, cob_common_legacy has not been released via bloom-release - I manually added this key...there will also not be any bloom-release cob_common_legacy in the future - I just want to keep the debian packages available in the pinned (legacy) version

I think the problem with this scheme is that it is tricky and different from all other releases in ROS, which is why we are balking at this. If you are no longer able or willing to maintain this repository in the future, it will be very difficult for anyone else to pick this up and understand what is happening here.

One alternative that I might suggest is to actually create a cob_common_legacy source and release repository, and only put in the raw_description and cob_description packages in it. That way it will look and behave the same way as all other repositories. What do you think?

[fmessmer]

I dont quite understand what is problematic about this. The two entries are completely separated by:

• disjunct package sets
• different release branch name
• different source branch name
• different tags

arent the branches in the release repo also package/branch/tag specific?

what would/could be potential (negative) consequences in the buildfarm/release workflow?
is there a way to test/simulate the consequences in some way?

I would like to avoid moving the legacy packages to a separate repo!

[fmessmer]

If you say this is too complicated, I will rather remove the legacy entries again

(especially as this is not just about cob_common, see the open PRs for cob_command_tools, cob_control and cob_driver)

But then, I will also have to remove all downstream packages depending on those (then removed) legacy packages for the noetic distro

[fmessmer]

I mean, eventually, we at 4am-robotics, do not require these repos to be updated/released anymore...

We could also just not update/release any package of the cob-repos at all and leave everything in its current state, i.e. close the current PRs.

I just thought to keep those for the sake of nostalgia 🙂

[clalancette]

what would/could be potential (negative) consequences in the buildfarm/release workflow? is there a way to test/simulate the consequences in some way?

The basic issue is that it is not possible for anyone to do releases again for this repository, without it end up being a confusing mess. And while I totally understand that you may not intend to do that, reality sometimes interferes and we need to do releases.

I dont quite understand what is problematic about this. The two entries are completely separated by:

* disjunct package sets

* different release branch name

* different source branch name

While they do have different source branch names, they have the same packages on multiple branches. And that will cause problems in the release repository. In particular, bloom-release will succeed with blooming either of them, but they will be "competing" to see which branch releases the shared packages.

I guess one other way to move forward here would be to remove all the duplicate packages on the kinetic_release_candidate branch. That would fix most of my concerns here (though not all of them; this would still be a special snowflake repository).

[fmessmer]

I thought about this some more...
I guess releasing the latest functional changes made to the (still maintained) packages is not worth the hustle of messing with the long-term stable releases of the cob_* series - at least there is no benefit for 4am-robotics but rather negative consequences for the buildfarm and other potential downstream dependencies

Thus, I guess it's ok then to just keep the last release (from Feb 2024) that still included all packages from the "old" source branch and just not trigger a release from the new dev branch - where now some packages have been dropped

With this decision, I would just close the PRs unmerged!

@clalancette would I have to cleanup something in the respective e.b. cob_common-release repository to undo this messed try?

I guess I will also bump the minor version of the new dev branches to free the version (patch) again for the old dev branch - in case there will ever be another release from there...

[fmessmer]

closing in favor of #41016