[ros-release] [Discourse.ros.org] [Release] Maintainer best …

Top Page
Attachments:
Message as email
+ (text/plain)
+ (text/html)
+ (text/plain)
Delete this message
Reply to this message
Author: Discourse.ros.org
Date:  
To: ros-release
Subject: [ros-release] [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.

To unsubscribe from these emails, [click here](http://discourse.ros.org/email/unsubscribe/e38c24220570c6523dcce4dbceb34d266108dd4a37375c90746b4e14cd325778).
_______________________________________________
ros-release mailing list

http://lists.ros.org/mailman/listinfo/ros-release