Thanks for your reply. I understand the point of the requirements of each package.
Precisely my point, why do you need to put efforts in regression of those changes? Unless you want to be stable in all distros, which can also be potentially hard to achieve anyway, right?
Perhaps this scheme clarifies both my concern and my suggestion:
Currently in most of ROS repositories (comm and leaves):
C5 <- C6 <- C7 <- [melodic]
/
C3 <- C4 <- [lunar]
/
C1 <- C2 <- C3 <- [kinetic]
For some reason, the bug fixed C3 was accepted in kinetic, but then cherry-picked/merged into lunar manually, that is, into a future release. So melodic and lunar will have a bug fixed that was manually added. But, melodic will have it only if the branching took place after C3 on lunar, otherwise it needs to be added manually too.
My suggestion would be (release-per-branch or tags, but keeping a single line of development):
C3 <- C6 <- [kinetic] [lunar] [melodic]
/ / /
C1 <- C2 <- C3 <- C4 <- C5 <- C6 <- C7 <- [master]
Where C3 is still a bug fixed, and add C6 if you want, merged into a previous release, namely kinetic. These fixes do not need to be manually added to either lunar and/or melodic, since they will have them by construction.
Correct me if I’m wrong, but wouldn’t the later makes it easier and safer to maintain for both comm and leaf packages? And still comply with both goals, have new features for new releases and still able to deal with regression stability?
Side note: Just interested in your points of view as a consumer of comm packages and developer of leaf ones.