Preparing for Noetic Sync 2022-05-04

Hello Noetic maintainers!

Starting now, I will be holding new Noetic ros/rosdistro release PRs with a plan to sync ROS Noetic packages to the main apt repo on 2022-05-04. Please comment here if there are any issues I should know about before performing the sync.

There are currently 32 packages waiting to sync and 0 regressions.

any chance to squeeze in the remaining meta-package releases for the cob_* series?
it’s just meta packages - no actual source-code…
it will require cob_manipulation: 0.7.6-2 in 'noetic/distribution.yaml' [bloom] by fmessmer · Pull Request #33014 · ros/rosdistro · GitHub to be merged + one upcoming PR for GitHub - ipa320/care-o-bot which I will provide as soon as cob_manipulation: 0.7.6-2 in 'noetic/distribution.yaml' [bloom] by fmessmer · Pull Request #33014 · ros/rosdistro · GitHub gets merged…


If it is not too late, would it be possible to include PR septentrio_gnss_driver: 1.1.0-7? It contains an important bug fix.

Looks like that PR is waiting for a LICENSE file. The good news is once you add one you don’t need to make a new release.

Looking at the changelog, it looks like there are tons of changes in that release. septentrio_gnss_driver/CHANGELOG.rst at master · septentrio-gnss/septentrio_gnss_driver · GitHub

I’d recommend merging that one after the sync instead so it gets maximum time in the testing repo.

I am sorry but I am not sure if I understand correctly. Does it mean it will stay on the previous version (1.0.8) or will 1.1.0-6 be merged (Sync page)? The latter also has the ton of changes and 1.1.0-7 fixes a bug. In essence, 1.1.0-6 should not be merged.

When the sync goes out the version in testing will be published to main.

Right now from the sync page you can see that 1.1.0-6 is in testing and 1.0.8-1 is in main.

Your pull request being held is proposing releasing 1.1.0-7. If it is held, 1.1.0-6 will be released in this sync.

If you believe that 1.1.0-6 contains a critical bug, our default recommendation at this point would be to roll it back to the previous release 1.0.8-1 because at this point it has not been released and the testing phase has found the bug. You can also request that the release manager make an exception for 1.1.0-7 to be released instead. However, as there will be no time for testing of 1.1.0-7 you run the risk of a bug in that release persisting in the main repositories until the next sync. This is a much higher risk operation and consequently you would want to make a strong argument for that instead of a rollback.

Somewhat related, you appear to be rereleasing/tagging different upstream content under the same version tag and then reblooming it with the same version number. This is strongly recommended against doing. In general reblooming with the same version number is intended for changes that are made in the release repository related to packaging without changes to the upstream content. We have made the process robust to retagging, but it causes extra work on the buildfarm etc to recover from the expectation that version x.y.z doesn’t change, and it’s only robust to certain types of changes within the source. This also represents a problem that reviewers no longer have visibility into what has changed. The changelog presented to the reviewers above includes all the changes in 1.1.0 vs 1.0.8 but what you’re actually releasing is maybe a oneline bug fix that can be considered much lower risk than a large change and should be represented as 1.1.1 not 1.1.0-X. And lastly this makes it a problem for users to know if they’re up to date. If they have already installed 1.1.0 and you retag 1.1.0 the users no longer have a way to tell if they’re up to date with the latest source.

The sync is out :tada: . Now is a great time to make releases for the next sync :bird:

Thank you @tfoote for your detailed explanation.

1.1.0-7 is an important fix but contains just two lines of code changed. Unfortunately, the sync has been done already with 1.1.0-6, which means we definitely have a bug in that release persisting in the main repositories until the next sync. Is it too late now or would it still be possible to squeeze in 1.1.0-7? Or would it be better to make the version 1.1.1 then?

Your explanation regarding reblooming and the rationale behind versioning is very plausible and we will take it into account for the future.

It’s too late for this sync, but the next one is just a couple weeks away. Making the next release now is the best thing that can be done.

Ok, thank you @sloretz for clarifying.