PCL 1.8.0 release

[taketwo]

After more than one year and over 600 commits since 1.7.2, I think it is time to consider releasing a new version. Below is a tentative checklist for the release preparation:

• check for API breakage
• decide (and clarify) which modules to release (related: Modules included in releases #1351)
• merge Real Sense grabber for Windows
• deprecate old Intel perceptual computing grabber
• finish SAC refactoring (Make SampleConsensusModel::getSampleSize() a virtual function #987, getSampleSize issue #987 #1344, SAC Models Refactoring: isModelValid() #1075)
• prepare a changelog (Update changelog for 1.8.0 release #1384)
• update LCCP interface and merge new CPC algorithm implementation (New interface for LCCP #1389, Implemented Constrained Planar Cuts algorithm (CVPR 2015) #1278)

There are two interesting work-in-progress items (default alpha values #1141, optimizations #1361), however I think it is hard to foresee all effects of applying them. The unit test coverage is far from 100%, so we can not be entirely sure that we don't break something. Therefore, I would avoid merging them shortly before the release.

Another issue that is worth attention is #1275, however I don't think that it should hold off the release. Once we have a solution, we can roll out 1.8.1.

[taketwo]

I am very close to completing the changelog (only two months worth of merged pull requests left). Any volunteers for the first item? Any conclusive thoughts about the second?

[SergioRAgostinho]

I can provide some assistance if needed.

1- You do you check API breakage? Try to compile and run 1.7.2 tests on the current HEAD?
2- I already expressed my opinion on that one.

[taketwo]

@jspricke As a seasoned maintainer, could you please explain the procedure for such a check?

[jspricke]

Good question, we never did it before but it would be great to document API changes in the release notes.
This link has a number of options:
http://stackoverflow.com/questions/1969916/static-analysis-tool-to-detect-abi-breaks-in-c/4747235#4747235

[SergioRAgostinho]

👍 I'll give a try over the weekend.

[SergioRAgostinho]

Status update:
Given the options, I went with ABI Compliance Checker, which seemed to be the only one I could "quickly" run on OS X.

• How to invoke it
• How to build the XML descritor with examples

My current approach is the create and XML for each module which generates a shared lib, starting with pcl_common. Here's an example of the xml descriptors I'm using in case you want to replicate.

<version>
    1.7.2
</version>

<headers>
    /opt/pcl/install_1_7_2/include/pcl-1.7/pcl/common/
</headers>

<libs>
    /opt/pcl/install_1_7_2/lib/libpcl_common.1.7.2.dylib
</libs>

<include_paths>
    /usr/local/include/eigen3/
    /opt/pcl/install_1_7_2/include/pcl-1.7/
</include_paths>

<version>
    1.8.0
</version>

<headers>
    /opt/pcl/install_1_8_0/include/pcl-1.8/pcl/common/
</headers>

<libs>
    /opt/pcl/install_1_8_0/lib/libpcl_common.1.8.0.dylib
</libs>

<include_paths>
    /usr/local/include/eigen3/
    /opt/pcl/install_1_8_0/include/pcl-1.8/
</include_paths>

And here's a first look into the only report I was able to generate, ignore the ABI report for now.

Small comments (concerns while traversing this uncharted territory experience):

• I won't be able to test pcl_visualization, because it's throwing compilation errors.
• I have the impression that I need to use the same compiler (gcc which is the only one supported) for building pcl and running the compliance checker tool. (I'll need to rebuild everything again)
• ABI checking requires compiling with no optimisations, generating and ABI dump and then passing that as a descriptor.

[taketwo]

Now I recall I used the same tool to check ABI compatibility between 1.7.1 and 1.7.2. For reference, here is a report from last time.

[SergioRAgostinho]

@taketwo Can you share the XML descriptors you used for all the modules. It would save me some time :)

[taketwo]

I found the report in my mail. I'll need to check another laptop to see if the descriptors are still stored somewhere.

As a side note, I was recently browsing OpenCV cmake scripts and came across a generator for ABI compliance checker: OpenCVGenABI.cmake. We may consider borrowing this.

[taketwo]

Checked. Unfortunately, I don't have these config files anymore.

[SergioRAgostinho]

So here's a bundle with xml descriptors, abi dumps, compatibility reports and logs. For the time being, I created the xml descriptors manually. This was done on Linux.

General comments:

• Most of the modules are incompatible 😢
• In average, There are situations where the source incompatibility rate (%) is always bigger that the binary. "Wait! What!? How is that even possible?" (see below).
• The Source compatibility report is missclassifying situations like the one below, reporting the symbol as missing/added. Fortunately enough, this appears to not break affect binary compatibility. So the idea is might be to focus the attention on the binary reports only first and then double check the source report.

int foo();  //old
int foo(int bar = 0); //new

• Modules which depend on other modules, "inherit" their incompatibilities (expected).

So... a small example of things that were broken...

pcl_common:

• pcl::Exception [ 1.7.2 , 1.8.0 ] - Public member's types were changed and some members were even removed. The class no longer has the same size, so all inherited types are now binary incompatible.

[jspricke]

Note that we are ok with ABI breakage (the minor version is part of the Soname).
Breakages in the API could be a problem, but as long as we document them, they should be ok as well.

[taketwo]

So what's the conclusion here? I'm done with the changelog, so this is the last item preventing release.