Some of my ideas: try to define “virtual types of distributions” that match stability vs new features. We could consider an “stable release” and “development release” and how these concepts fit into the ROS releases:
- stable release: most of the users, any disruptive change should not be permitted only important bug fixes to be committed.
- development release: brave users expecting fast new features and able to adapt quickly to changes.
At this moment I would say that Indigo would fit perfectly in what we consider a stable release. I’m not so sure about Jade. Probably Kinetic can fit well into what we can consider a development release. Obviously the upcoming Lunar falls into this category.
Reviewing the types of changes that I listed in my first post:
-
Bugs: if they fix things clearly broken, stable and development.
-
Changes to the API: clearly unacceptable for stable. If we consider
Kineticas a development release they probably are acceptable although they are have a large impact. -
Changes to the ABI: given the position of ROS in this topic, they should not represent a problem except for people relying on mixing packages and catkin builds. I would probably exclude stable of this.
-
Changes that affect rostopic/roslaunch/rosparams/… names or arguments: in most the cases the impact could be really important, even worse than modifying the API since problems could not be directly visible.
-
Changes that affect behaviour (some of them are bug fixes): this category or group is difficult to manage. Take this PR as a good example of how a clear bug fix needs to be handle with care. I would say that have a case by case analysis and decision is a good way but by default anything touching a behaviour in an stable release (even if clearly fix it in the right way) should not be accepted.
There are other models if we define other “virtual types” of distributions (for example having Jade as a testing release before changes landed into Indigo) but I would like to keep the whole thing somehow simple.