[ros-users] [Discourse.ros.org] [Release] Maintainer best pr…

Top Page
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Discourse.ros.org
To: ros-users
Subject: [ros-users] [Discourse.ros.org] [Release] Maintainer best practices handling changes through ROS releases

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 `Kinetic` as 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](https://github.com/ros-simulation/gazebo_ros_pkgs/pull/397) 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.

[Visit Topic](http://discourse.ros.org/t/maintainer-best-practices-handling-changes-through-ros-releases/771/2) or reply to this email to respond.

If you do not want to receive messages from ros-users please use the unsubscribe link below. If you use the one above, you will stop all of ros-users from receiving updates.
ros-users mailing list

Unsubscribe: <http://lists.ros.org/mailman//options/ros-users>