[Documentation] [TitleIndex] [WordIndex] 

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:

... 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:

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:

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:

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

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:

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

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:

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://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.

2024-12-07 14:58