Pcl: 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 #2792
• [x] thread, mutex, condition #2700
• [x] functional, binds #3079, #3128
• [x] type traits #3096, #3105
• [x] tupple #3250
• [x] unordered_map #3107
• [ ] random generators #2963, #2964,#3069, #2988, #2985, #2803, #2955
• [x] chrono
• [x] VTK component selection #3032, #3140
• [x] RSSDK 2 grabber #2214, #3467, #3481, #3490
• [x] properly deprecate function removed by #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]

:+1: 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,
   
   
   
   1. MINOR version when you add functionality in a backwards-compatible manner, and
   
   
   2. 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"?

[taketwo]

As far as I remember there is a Gitter room for PCL, so we can have an online discussion there. I'll be available first half of the day 2nd and during working hours 3rd.

[SergioRAgostinho]

Works for me for the full periods you suggested. There is indeed a Gitter channel. Let's see if someone else joins in.

[SergioRAgostinho]

Let's chat tomorrow 2PM CET on Gitter?

[taketwo]

I have an exam appointment between 2 and 3 that quite unexpectedly landed in my schedule. Will be free to join immediately after.

[SergioRAgostinho]

Let's start at 3 then. I'm not sure if anyone else will show up. ^^

[SergioRAgostinho]

Testing the waters here: after noticing the potential API breakage that the transition from boost to std is causing I'm starting to question if it won't be better to call the new release PCL 2.0.0.

[taketwo]

I'd be against. We've broken API on multiple occasions before and did not bump major version. If we were to follow strict semver, even when we remove deprecated functions we would need to do a major release! This we clearly don't do, so in PCL we tend to follow "loose" semver. With this in mind, I don't see a reason to suddenly become strict about potential (and hopefully mild) API breakage.

Now think about it this way. There is a library that doesn't strictly follow semver. This library makes 2.0 release. What would you expect from this release? I would expect new features, huge refactorings/rearrangements of modules, updates to the core. Certainly waaaay more than just s/boost/std/g. So I would feel totally like a blowhard if we call this PCL 2.0.

[Morwenn]

Semantic versioning has at least one big advantage: package managers tend to follow it when possible when asked to upgrade a library to a compatible version. I've been using PCL with Conan, and it does take into account semantic versioning when asked to pick compatible dependencies (and AFAIK considers anything that looks like semver to be semver).

If you had to switch versioning schemes, the most obvious thing to do would be to write a big disclaimer somewhere and to make sure that it is among the first things mentioned in the changelogs.

[vcarpani]

Any updates on the release?

[SergioRAgostinho]

Life took over and I have not been able to sit at the desk during my free time.

[aslze]

How about a 1.9.2 release in the mean time?

1.9.1 was released on November 2018 and it contained bugs that have been fixed since then.

[SergioRAgostinho]

It's not that easy anymore. We merged a number of things to master alongside bugfixes, including the very breaking changes while replacing boost code std alongside API changes. I don't think it's worth the trouble to go through all the bug fix PRs, try to cherry pick them and then have to fix whatever incompatibilities might have appeared. Just my 0.05$. The way forward is to finish the pending items and release.

[aslze]

OK, I see.
And apart from possible API changes, are there different compiler requirements between 1.9.1 and master (to be 1.10)? Will it work on VS 2013 as before or will need newer versions?

[taketwo]

are there different compiler requirements between 1.9.1 and master (to be 1.10)?

Yes, 1.10 will require full support of C++14 standard. Therefore, I assume VS2013 will not work.

[kunaltyagi]

@aslze As per this table and a quick grep for variadic templates, at least VS 2015.2 is required for PCL 1.10. I don't know how much the constexpr or default member init usage is. Maybe someone can compile using it since the CI uses VS 2017

[taketwo]

My work on smart pointer transition has stalled a while ago and currently, I don't have time to proceed with it. This delays the next release (which is already overdue) by unknown time. I feel we should drop most of the items from the 1.10 milestone and release soon, the diff to the previous release is already enormous.

I've checked the milestone items and the TODOs from Sergio's list. I think the following two are the most important, the rest can be moved to 1.11:

• Remove push/pop in PCLConfig #2726
• Properly deprecate function removed by #2798

@PointCloudLibrary/maintainers what do you think?

[SergioRAgostinho]

I agree. Some of the pending items require some proper time investment in order be properly fixed.

As an example, I've tried at least 3 times to venture into finishing the migration of the random generators withing sample_consensus and in all three, I quickly ran out of time before being able to reach any meaningful conclusion as to why the changes were triggering unit test failures.

[SergioRAgostinho]

I forgot to add, it is worth to merge #3345 as is and address the pending items later, if we are to close the milestone.

[simonschmeisser]

Just curious, is there a new estimate for when this will be released? There is about one month left for getting this into Ubuntu 20.04 which could be considered a goal? (Not saying it's still a realistic goal but even arbitrary deadlines can sometimes be helpfull ... :wink: )

[SergioRAgostinho]

Good to know and agreed. I'll see what I can do. :wink:

[kunaltyagi]

I'm back from my holidays, so I can chip in

[taketwo]

Thanks for the ping. I think getting this into Ubuntu 20.04 is a goal worth pursuing.

Big question is: do we want to flip the boost::shared_ptr -> std::shared_ptr switch before the release or not? I know this has been the plan all the way. But honestly, I feel uneasy about making this change and hastily tagging 1.10. This version will get "baked in" the next Ubuntu LTS. What if there are some tricky issues that we have overlooked?

[kunaltyagi]

do we want to flip the boost::shared_ptr -> std::shared_ptr switch before the release or not?

I think yes because it was delayed for the switch (one of the TODOs).

I feel uneasy about making this change and hastily tagging 1.10

If Sergio is also hesitant, we could release in 2 different modes, conflicting with each other: say pcl-std, pcl-boost. I know it's possible on Ubuntu, Arch and MacOS (but might not be possible on vcpkg)

[jspricke]

• Kunal Tyagi [e-mail] [2020-01-09 17:34]:
  >> do we want to flip the boost::shared_ptr -> std::shared_ptr switch before the release or not?
  >
  >I think yes because it was delayed for the switch (one of the TODOs).

I vote no. If a feature is not tested, it's not ready.

I feel uneasy about making this change and hastily tagging 1.10

If Sergio is also hesitant, we could release in 2 different modes, conflicting with each other: say pcl-std, pcl-boost. I know it's possible on Ubuntu, Arch and MacOS (but might not be possible on vcpkg)

I don't think we will get such a big change in time into Ubuntu.

Note that we set the soversion to major.minor, so 1.10 will be the new
ABI version (I didn't check if there is actually a ABI break). That
means we need to go through the Debian ftp-masters and request a
transition slot from the release team. So I'm not sure if we could make
it into Ubuntu 20.04 at all (but will help as much as I can).

[Morwenn]

From a user POV I'd that getting a new version that works is more important than the shared pointer change. I would even say that letting another version flow before the switch is better: it lets them the time to change boost::shared_ptr to pcl::shared_ptr without their coding breaking right away, which is a smoother path forward than breaking everything directly.

[kunaltyagi]

it lets them the time to change ... without their coding breaking right away

We added aliases this release, so maybe it makes sense not to flip the switch but to instead release it later.

At the same time, we should release it with the switch soon (maybe as 1.11 for 20.10 instead of 20.04) because we wouldn't know what issues crop up till we do it and preferably with little to no changes to the code (just the flip ie.). There's plenty of time for testing till then.

pcl::shared_ptr

There's no such thing (I think) 😄

I don't think we will get such a big change in time into Ubuntu

Did you mean 2 flavors or the flip?

[Morwenn]

Oh? I read the issue about pcl::shared_ptr and thought it was a thing since it was mentioned, my bad ^^'

[taketwo]

@jspricke @Morwenn thanks for the inputs.

1.10 will be the new ABI version (I didn't check if there is actually a ABI break)

Absolutely, at the very least because we jump from C++98 to C++14.

From a user POV I'd that getting a new version that works is more important than the shared pointer change.

Same assessment here. In the last months, we put some effort into making sure that all API-visible smart pointers are hidden behind typedefs. Thus ideally, the shared pointer change will be invisible to the users. And if it is invisible, why would they even care? :smile:

I would even say that letting another version flow before the switch is better: it lets them the time to change boost::shared_ptr to pcl::shared_ptr without their coding breaking right away,

As @kunaltyagi mentioned, we don't have pcl::shared_ptr. But the argument still holds: the users will have time to change raw boost::shared_ptr to Ptr typedefs. (Note that such typedefs were missing for some types and were added very recently).

At the same time, we should release it with the switch soon.

I'm pro flipping in master immediately after release and then getting 1.11 relatively soon.

[jspricke]

• Kunal Tyagi [e-mail] [2020-01-10 03:19]:
  >> I don't think we will get such a big change in time into Ubuntu
  >
  >Did you mean 2 flavors or the flip?

2 flavors.

[taketwo]

I've tagged 1.10.0.

@jspricke what are the steps we need to take to get this version into Ubuntu 20.04?

[UnaNancyOwen]

Congratulations 1.10.0 Release! 🎉
I start creating the PCL 1.10.0 All-in-one Installer.

[kunaltyagi]

I can create the darwin package for Mojave (10.14.6)

[jspricke]

• Sergey Alexandrov [e-mail] [2020-01-19 08:53]:
  >I've tagged 1.10.0.

Awesome, congrats!

@jspricke what are the steps we need to take to get this version into Ubuntu 20.04?

I will work on it. We need to get into Debian first ;).

Cheers Jochen

[UnaNancyOwen]

PCL 1.10.0 All-in-one Installer released! 👍
I was created only x64 version. (I will be create x86 version if there is user's request.)

[kunaltyagi]

Mojave package too :) (Don't know if it'll work on other systems though, didn't test that)

[SergioRAgostinho]

Congrats guys :)

[skhadem]

Hello, sorry if obvious (I am new to PCL), but it seems the All in One does not include io/real_sense_grabber.h? Am I missing something? Thanks.

[UnaNancyOwen]

@skhadem Pre-built PCL included in PCL All-in-one Installer is built with basic options.
If you need other features such as grabber for RealSense, Please build PCL from source code yourself.