Contents

  1. Development Model
    1. Proposed development model
      1. Versioning Policy
      2. Release Schedule
      3. API Changes between Versions
      4. ROS Packages
    2. Potential (late) future changes to the development model

Development Model

Following a discussion thread on pcl-users@code.ros.org (see here), we propose the following development model for PCL.

Proposed development model

PCL will follow the ROS distribution model, with a major release every 6 months. The first major release (1.0) is tightly coupled with the release of Diamondback (aka D-Turtle), the next major release is to be expected in E-Turtle, the next one in F-Turtle, etc.

In principle, the versioning system can be chosen as similar to:

[add more versioning models here if they are relevant]

Versioning Policy

The best model for a library like PCL which needs to iterate fast at the moment, seems to be given by http://en.wikipedia.org/wiki/Software_versioning#Change_significance: In principle, in subsequent releases, the major number is increased when there are significant jumps in functionality, the minor number is incremented when only minor features or significant fixes have been added, and the revision number is incremented when minor bugs are fixed.

We want to offer our users the chance to work on:

  • a stable branch, so they can build solid applications on top. We can keep the API 100% fixed and do only patch releases (or additionally we can consider adding minor features that do not break the API -- need a discussion about what's considered minor) -- so all in all, API should be 100% backwards compatible;

  • a devel branch, where we add some of the latest and greatest features. Here we do our best to keep the API stable, but there are no guarantees. For examples, if we discover that the current sample consensus segmentation API is not really good, we need to go ahead and change it.

... and we want both these branches in the same ROS distribution. Obviously non-ROS users will not care too much, and they will download whatever they think is best suited for them (more iterated and stable but without all the features -- e.g. stable, or potentially unstable but with better functionality -- e.g., devel).

That being said, we will try to guarantee:

  • up to 100% API backwards compatibility between releases. New releases should build on top of the old releases and add new features, and attempt not to break the base API through any core modifications;

  • any new API modification decision has to be supported by a strong case/argument. The proposer needs to clearly explain why the current API cannot accommodate the existing design decisions.

The above two points will hopefully address the -- what it may seem -- rapid development pace, as shown in the next section.

Release Schedule

With this in mind, the versioning roadmap could look as follows:

  • D-Turtle (6 months):

    • PCL 1.0 -- released in D-Turtle -- stable after API review;

    • PCL 2.0 -- released in D-Turtle -- devel, active development goes here;

  • E-Turtle (6 months):

    • PCL 1.0 -- marked as deprecated;

    • PCL 2.0 -- marked as stable after API review;

    • PCL 3.0 -- released in E-Turtle -- devel, active development goes here;

  • F-Turtle (6 months):
    • PCL 1.0 -- removed;

    • PCL 2.0 -- marked as deprecated;

    • PCL 3.0 -- marked as stable after API review;

    • PCL 4.0 -- released in F-Turtle -- devel, active development goes here;

Therefore, throughout a major release, we guarantee not to break the API for the stable branch. Our users can decide if their application needs stable iterated code, or whether it can live with more experimental code. The fact that they can go back and forth (hopefully with no changes or minimal changes in their code) in the same ROS distribution is useful for us -- as they might decide that it's worth helping us out to stabilize the devel branch sooner, as it contains very useful features, etc.

API Changes between Versions

Every new version of PCL needs to have its own namespace, so as to not collide with previous PCL versions. Example:

  • namespace pcl -- will define the namespace for PCL 1.x;

  • namespace pcl2 -- will define the namespace for PCL 2.x;

  • namespace pcl3 -- will define the namespace for PCL 3.x;

  • ...

In addition, the include subdirectory structure needs to be changed too. The header files will be stored in:

  • include/pcl -- in PCL 1.x;

  • include/pcl2 -- in PCL 2.x;

  • include/pcl3 -- in PCL 3.x;

  • ...

In theory, this allows the user to mix and match algorithms from different versions of PCL, although (s)he will be discouraged to do so, through the use of a best practices document. However, we do not want to make this a hard constraint. This means that although methods that operate on pcl::PointCloud<T> cannot be used on pcl2::PointCloud<T>, there's nothing that prevents the user to write a bridge method/class that does the conversion either through casting (if no changes have been made in that class) or data copying. We could also provide such a class for our users, but we will keep it in an external package, outside of PCL.

ROS Packages

The ROS PCL packages will be named according to their version number. We therefore expect:

  • ROS D-Turtle to contain two packages: pcl and pcl2;

  • ROS E-Turtle to contain three packages: pcl, pcl2, and pcl3;

  • ROS F-Turtle to contain three packages: pcl2, pcl3, and pcl4;

  • ROS G-Turtle to contain three packages: pcl3, pcl4, and pcl5;

  • ...

Packages that depend directly on PCL and are bundled in the same ROS stack will follow the same convention:

  • pcl_ros will be named pcl_ros2 if it depends on pcl2;

  • pcl_visualization will be named pcl_visualization2 if it depends on pcl2;

  • ...

Potential (late) future changes to the development model

The reasons for the above scheme are obvious. PCL needs to iterate fast in order to find the best base classes, best base algorithms, etc. Therefore the structure of the base classes might change from pclX to pclY, etc.

HOWEVER, we anticipate that after a few major releases, we will reach a point where most of the basic things have already been solved. This means that when that point is reached, we might change to a different development model, that includes:

  • one pcl base package which contains the core which is rock-solid API stable and we don't expect it to change for a long long time;

  • one pcl_experimental add-on package which contains new features and algorithms which make use of the base classes but do not need any modifications for them in order to run.

All new classes will therefore be added to pcl_experimental, until they become stable (through usage and API review) so they can be migrated in the pcl package.

This might affect both ROS and non-ROS users, as we will provide a -lpcl and -lpcl_experimental in two TGZ archives separately. See http://www.ros.org/wiki/pcl/standalone for more information.

Even further into the future, we can imagine changes at the methods level, where we can re-consider things such as __attribute__ ((unstable)) [doesn't exist, but maybe we'll make one until then ;)], or BOOST_STATIC_ASSERT (USE_PCL_EXPERIMENTAL), etc.

Wiki: pcl/Roadmap (last edited 2011-03-31 17:30:37 by RaduBogdanRusu)

Except where otherwise noted, the ROS wiki is licensed under the
Creative Commons Attribution 3.0