1.10.0 Release

[SergioRAgostinho]

I'll add the task list later. I just want to converge on the approximate date. I would propose early/mid April, after ICCV and IROS deadlines if I'm not mistaken.

I'm also looking to converge on the essential features to be released. I'm aiming at finishing the C++14 migration, or getting close to.

• memory Transition to standard smart pointers #2792
• thread, mutex, condition Migrating from Boost.Thread to std #2700
• functional, binds Migrate boost::function to std::function #3079, Add registerCallback() overload to grabbers to support assignment of boost::functions with templated signatures #3128
• type traits type_traits migration #3096, Migrate to standard library type traits #3105
• tupple Migrate from boost::tuple to std::tuple #3250
• unordered_map Migrate from boost::unordered_map to std::unordered_map #3107
• random generators Use random generator from C++11 instead of from Boost in module sample_consensus #2963, Use random generator from C++11 instead of from Boost in module filters #2964,Replace random_shuffle by shuffle #3069, Use C++11 random generator instead of Boost in RangeLikelihood #2988, Inconsistent handling of default seed in NormalGenerator & UniformGenerator  #2985, Replace boost::mt19937 with std::mt19937 #2803, Replace UuidGenerator of Boost in OutofcoreOctreeDiskContainer #2955
• chrono
• VTK component selection Use COMPONENTS when finding VTK #3032, Use COMPONENTS when finding VTK to avoid linking agains unnecessary modules #3140
• RSSDK 2 grabber Add RSSDK 2.0 (librealsense2) grabber #2214, Changes to RSSDK 2.0 grabber #3467, Configuration fails on Linux host with librealsense2 installed #3481, Downgrade RSSDK2 warning message to status. #3490
• properly deprecate function removed by Replace pcl_isnan, pcl_isfinite and pcl_isinf by C++11 methods #2798

Tentative schedule:

• May 12th June 9th - 1 5 week just to get the PRs out
• May 26th June 23rd - 1-2 weeks to review everything.
• June 9th July 7th - 1-2 weeks prepare the actual release. Revise PR labels and titles

[taketwo]

👍 for keeping up with regular releases. We are still not a C++14 library when it comes to officially released versions, so the sooner the new version comes out, the better. I'm fine having April as our target, though I won't be strict about this.

As a long-term goal I would like to have Boost types in the library API to be replaced with std types (e.g. shared_ptr, function). Of course, this transition should not break source code level compatibility with previous releases. I don't have a clear strategy in mind yet, but it may be that a smooth transition would need to stretch over multiple releases. So I think we should figure this out soon and, in case a multi-phase transition is required, include the first phase in 1.10.

Edit: I've started #2792 to discuss smart pointer transition.

[claudiofantacci]

As far as transitioning to C++14 and new release version is concernd, since moving from Boost to STL introduces breaking changes, shouldn't the targeted release for C++14 be a major one?
Not really sure whether I already discussed about this or not, but is PCL following SemVer? (btw, it would be useful to do so)

[SergioRAgostinho]

I believe PCL 2.x.x was reserved for really big changes e.g. a templated free version of the library following in the footsteps of OpenCV. Without funding I don't see this happening, so I'm open to discussion on this.

The current status is:

• 1.9.x to 1.10.x implies API breakage or serious behavior changes
• 1.9.1 to 1.9.2+ implies full compatibility.

[claudiofantacci]

@SergioRAgostinho thanks for the explanation 👍
If not written elsewhere, I would encourage to write this versioning meaning somewhere, e.g. in the main README file. What I would do is to use SemVer, but as long as something else is adopted and documented for me is just fine. 😄

[taketwo]

I believe PCL 2.x.x was reserved for really big changes.

Exactly. (At least in my head) version 2 is reserved for a major revision of the library. Anything short of that would not fulfill expectations.

Is PCL following SemVer?

I'd say we loosely follow SemVer. The SemVer rules are:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. PATCH version when you make backwards-compatible bug fixes.

On the PCL side we

1. Reserve MAJOR for a large library revision.
2. Bump MINOR at breaking ABI changes and (in certain cases) API changes
   1. When API change is minor and (supposedly) shouldn't affect many users or otherwise cause trouble
   2. When the change is removing APIs deprecated several MINOR revisions before.
   3. When the change happened by accident ;)
3. PATCH is for fully-compatible updates, which occasionally may include new features.

[claudiofantacci]

On the PCL side we

1. Reserve MAJOR for a large library revision.

2. Bump MINOR at breaking ABI changes and (in certain cases) API changes
   
   1. When API change is minor and (supposedly) shouldn't affect many users or otherwise cause trouble
   2. When the change is removing APIs deprecated several MINOR revisions before.
   3. When the change happened by accident ;)

3. PATCH is for fully-compatible updates, which occasionally may include new features.

Thanks! 👍
My two cents here is to write it somwhere, maybe even in the main README file so that people knows what to expect from a new release version 😄

[taketwo]

My two cents here is to write it somwhere

Time, time... I've created an to-do issue though.

[claudiofantacci]

Time, time... I've created an to-do issue though.

Eheh sure, didn't want to push anyone to rush for it 😄

[SergioRAgostinho]

I'm aiming at investing one week worth of time around early May (5th onward) to push for this release. @PointCloudLibrary/maintainers If any of you has some time to spare around that period let me know so we can decide on the goals and light sprints. @claudiofantacci and @SunBlack the same question and offer extends to you both.

Edit: Or anyone else who reads this post and wants to contribute.

[taketwo]

I support the idea of pushing for the release, would be nice to get it out soon. Unfortunately I can not commit to spending much more time than I normally do, but I will try increase my availability for speedy reviews, discussions, and testing.

[SergioRAgostinho]

Sounds good. Shall we have a quick chat over Skype/Slack/Gitter/something sometime between 2nd-3rd of May just to agree on the "work package"?