Recommended workflow for maintaining changelog.rst file and tags properly with multiple releases?
What's the best way to maintain the changelog.rst file in the following situation?
- the package has a git repository with 3 branches: master, humble, rolling.
- development happens in "master".
- the branches "humble" and "rolling" are for release.
- at release time I want to apply some (usually all) of the new commits to master to the "humble" and "rolling" branches (they are not expected to diverge from each other anytime soon), and release those.
How do I accomplish this best? Is "changelog.rst" supposed to even show up in "master" (right now it does, giving me grief during release), or just in the release branches? Do I run "catkin_generate_changelog" then separate in "humble", "rolling"? Same with "catkin_prepare_release"? Won't the tags (which are global to the git repo, I believe) then conflict with each other, since e.g. both "humble" and "rolling" branch will/could have the same package number?
perhaps a strange question, but if there is no difference between the packages for Humble and Rolling, why branch?
It's perfectly OK to release the exact same package into multiple different ROS versions.
I could not find any instructions on how to use catkin_generate_version and "bloom" to release the same package multiple times into separate distros. It would be convenient to do so but it's not that much work going through the steps twice. The key trick (provided in your answer to another question, see below) is to use different minor version numbers so there is no tag collision. That works for now.
It could probably be documented better, but there isn't really any 'process': just point bloom to the same tag in your source repository and run through the process.
You'd reuse the source artefacts, not the release artefacts (that'd be impossible, as different ROS 2 versions need different files to build binary packages).
That'd be it.