Update changes for 1.8.1

[SergioRAgostinho]

I appended an authors list at the end. Let me know if you want them removed, since we do have an Authors.txt lying around.

[VictorLamoine]

Isn't https://github.com/PointCloudLibrary/pcl/graphs/contributors enough?
Manually maintaining a contributor list is tidy work.

[jspricke]

+1 for leaving out the authors. Thanks for the work @SergioRAgostinho :). I guess we wait with this till everything else is merged.

[SergioRAgostinho]

You both have a point. If Sergey had to do this on that massive 1.8.0 changelog... don't want to imagine 😄 Well but for this one, since I've already collected the list (which is not big), we can at least acknowledge them on the oficial email announcing the release.

I'll update the changelog again on our final RC.

By the way, where/how do we update the version in the docs? Are there any more places where the version needs to be bumped?
Also, should we not bump the version to 1.9.0 some time after we release 1.8.1?

[VictorLamoine]

The documentation version is automatically generated thanks to CMake macros;

The PCL version is defined here:
https://github.com/PointCloudLibrary/pcl/blob/master/CMakeLists.txt#L194

All the files with the suffix .in will be modified by CMake macros (this is not automatic and the suffix is not mandatory)

$ find . -iname "*.in"
./doc/doxygen/doxyfile.in
./PCLConfigVersion.cmake.in
./cmake/uninstall_target.cmake.in
./cmake/cpack_options.cmake.in
./cmake/Modules/NSIS.template.in
./cmake/pkgconfig-headeronly.cmake.in
./cmake/pkgconfig.cmake.in
./pcl_config.h.in
./PCLConfig.cmake.in

For the Doxygen documentation the macro is applied in doc/doxygen/CMakeLists.txt, every variable enclosed in two @ characters will be replaced with their respective CMake values. See line 6 of doxyfile.in for an example.

[taketwo]

This page we need to update manually.

[taketwo]

Also, should we not bump the version to 1.9.0 some time after we release 1.8.1?

We used this approach before, e.g. we bumped version to 1.7.2 immediately after 1.7.1 was released. It's not very convenient, however, because the decision about the numerals of the next version has to be made in advance. What if we bump to 1.9.0 now, but soon after the release it will become clear that there is a nasty bug and we need 1.8.2 release?

An alternative would be to adopt an approach similar to OpenCV. The trunk version consists of the most recent released version with the "-dev" suffix. E.g., right now the most recent version is "3.1.0", and trunk compiles to "3.1.0-dev". When it's time to release, they will change the version "3.2.0" or "3.1.1" (as is appropriate), create release tag, and then immediately append back "-dev" suffix.

[taketwo]

Any opinions there? Should we switch to OpenCV way?

[SergioRAgostinho]

Sorry. Sounds good to me!

[jspricke]

+1 for adding a "-dev" suffix.

[taketwo]

I'm afraid there is a problem here. Our PCL_VERSION macro is numerical (e.g. 100801 for version 1.8.1). We can not just append "-dev" suffix to it as it will break conditional compilation in third-party libraries (e.g. constructs like #if PCL_VERSION >= 100702).

[SergioRAgostinho]

I searched for the number of occurrences of PCL_VERSION in our source and they're tractable i.e. leave PCL_VERSION untouched and create a new var like

PCL_VERSION_FULL="${PCL_VERSION}-dev"

There will be places where it should be harmless to replace that PCL_VERSION for PCL_VERSION_FULL. In theory this should be ok.

Edit: Feel free to come up with a more elegant name ^^

[taketwo]

Yes, we can have a second variable thus making sure that third-party projects are not broken. But the problem is somewhat deeper because it won't be possible to check version with that simple comparison macro. If we do not bump current version after release and only append "-dev" suffix, the master branch will remain with the same numerical version as released version.

I have two options:

1. Always bump revision version after release. When the time comes for the next release, bump minor as well if needed. To emphasize the development status add "-dev" suffix in CMake output, documentation, etc where appropriate. Simple version check macros will work.
2. Don't bump revision, only add "-dev" suffix. Improve already existing PCL_VERSION_COMPARE macro function (see example usage here) to take into account "-dev", and make it the only officially supported and recommended way to check PCL version.

[SergioRAgostinho]

Let's entertain the second option.
With the following variables:

PCL_VERSION (numerical)
PCL_VERSION_DEV (bool)

This should allow to properly construct a proper "version-dev" string and simplify version compare greatly.

(I'm starting to feel that I'm "solving" all my problems with more variables 😅 )

[SergioRAgostinho]

Change log updated

[taketwo]

So, merge this and start with release process?

[jspricke]

Sounds good to me :).