When will there be a new release of master?

[v4hn]

Hi everyone, in particular @jslee02 @sherm1 @SeanCurtis-TRI, I guess.

I guess I ask this in the general interest of the ROS/MoveIt community.

There were lots of contributions to the library (many labeled "fixes"),
that are currently in upstream master but not released.
The last published release is 0.3.4 - a backport release @jslee02 did last year.
0.5.0 was released over two years ago.

In ROS kinetic there are unofficial custom snapshots via https://github.com/wxmerkt/fcl_catkin ,
but even they are not up to date anymore.

Ubuntu 18.04 (and thus ROS melodic) at the moment use 0.5.0 (https://packages.ubuntu.com/bionic/libfcl-dev),
which is older than the snapshots mentioned above.

There has been quite a bit of discussion on problems with FCL and possible advantages of the Bullet checker in MoveIt lately and outdated code probably makes things worse.

What's the situation?
Does it not make sense to do a new release because you broke the whole API and it's not settled yet?
Do you miss the developers to do a release?
Did performance only decrease since 0.5.0 and you struggle to improve on it again?

[SeanCurtis-TRI]

Some excellent questions. And, while not immediately obvious, this is tangentially related to #329. One of the things we'd discussed vis a vis #329 was releasing a new version for some of the reasons you've outlined above. You've just provided even more reasons above and beyond those already considered. So, bumping FCL seems like the right thing to do.

[v4hn]

I'm very happy to hear that! 👍 With all the discussion points in #329, please keep in mind that - the core of a release is only a tag in the git and the resulting tarball. Everything else is a very much appreciated bonus, but please don't leave releases pending long just because you cannot take care of the overhead of releasing it into 5 different packaging systems right away. If people want the software in some system, someone will take care of it eventually. - Looking at the pretty deep under-the-hood changes you discuss, I think it would be a good idea to do a release *before* you start doing them :) Thank you so much for your work in this project everyone!

[wxmerkt]

@v4hn There is a newer working version which includes the latest fcl-master (here), however, not yet released to the ROS build farm (I am traveling at the moment and plan to release it to the buildfarm this weekend or early next week).

I do agree and support a new release before #323/#329 (as in #323 (comment)).

[v4hn]

I'll add a friendly ping here.

We looked into making MoveIt compatible with your current FCL master branch today,
during World MoveIt Day.
Because of all the renames this becomes quite a lot of changes and it probably only makes sense to add that code once you actually released...

[v4hn]

Here is the pull-request, mentioned above, to adapt MoveIt for the new FCL API for reference:
moveit/moveit#1156

At the moment we plan to wait for your release before we merge the request.
You forced us to use the new API functions for compatibility with FCL 0.5 and 0.6
and it would be nice to depend on officially released API in MoveIt's official code base.

[v4hn]

another friendly ping. We are still waiting for a release.

[sherm1]

There is a release-candidate tag now: https://github.com/flexible-collision-library/fcl/releases/tag/0.6.0RC

[scpeters]

@j-rivero @SeanCurtis-TRI let's discuss here a 0.6 release

[SeanCurtis-TRI]

Let's get the official timeline for getting this into Ubuntu 20. And we'll look at the issues that we were hoping to resolve prior to moving from RC to final release.

[j-rivero]

The end of Debian imports for the next Ubuntu happens at the end of February. I would need some time to prepare the new upload and handle the library transition (libfcl0.5 to 0.6). This involves the participation of other Debian developers. Does February 10th works for you as death line to release 0.6?

[SeanCurtis-TRI]

If Feb 10 is the line we need to work with to make sure you can do your job and we can address any issues that come up, then so be it. Let's go ahead and draw that line.

We'll independently figure out if we can meet it. :)

[SeanCurtis-TRI]

@j-rivero I think we'll be good for targeting Feb 10th.

I just want to make sure I understand the division of labor so that we don't miss anything. I infer from your message that if we get the repo in a "good' state, you'll be handling preparing the Debian package and all of those fun and games? Or have I misunderstood that?

Ideally, if you could enumerate exactly what you need from us by the 10th, I can make sure it's done.

[j-rivero]

Ideally, if you could enumerate exactly what you need from us by the 10th, I can make sure it's done.

Sure. In Debian we usually work with stable releases from upstream project. Anything that you (as upstream project) consider a stable release should be enough for me to work on packaging and having the corresponding mechanisms in place in order to be compliance with Debian/Ubuntu policies.

[scpeters]

and to be more explicit, I think @j-rivero would like @SeanCurtis-TRI to make a release using the GitHub web UI, which will create a tag?

[j-rivero]

and to be more explicit, I think @j-rivero would like @SeanCurtis-TRI to make a release using the GitHub web UI, which will create a tag?

Not strictly necessary for me but I think that is the current way of creating fcl releases so makes total sense to me yes.

[jwnimmer-tri]

Ideally, if you could enumerate exactly what you need from us by the 10th, I can make sure it's done.

@SeanCurtis-TRI another observation related to schedule -- ideally, prior to tagging a release here, all of the changes would be fully vetted by both Drake CI and TRI's internal CI. Those extra tests might isolate some failures that FCL's own suite would miss. That probably needs a day or two of extra soak time prior to the 10th where all release-targeted FCL commits have already been merged to master.

[SeanCurtis-TRI]

That was exactly my idea as well. :)

[SeanCurtis-TRI]

@j-rivero I believe we're ready to go. Release 0.6.0 has been through its own CIs, Drake's CI, and our internal project's CI. So, I'm going to pass the baton to you -- let me know if you encounter anything that requires further attention.

[arocchi]

@v4hn @wxmerkt FYI

[scpeters]

updating homebrew formula: Homebrew/homebrew-core#49975

[wxmerkt]

Thank you all for the great effort in pushing this forward :-). I will make a new release of fcl_catkin to Kinetic/Melodic once the CI goes green for it.

[SeanCurtis-TRI]

@j-rivero How is this going? A couple of things have come up recently which may want us to shift to 0.6.1 as the Ubuntu release. Is that possible?

(#450 and #452)

[j-rivero]

@j-rivero How is this going? A couple of things have come up recently which may want us to shift to 0.6.1 as the Ubuntu release. Is that possible?

The upload is still being reviewed by Debian developers, not sure if we will get in on time. In the good news part, yes, we can send a 0.6.1 as the new version. Create the new release in github a will upload it.

[SeanCurtis-TRI]

@j-rivero For what it's worth, there's a 0.6.1 available.

[v4hn]

Thanks again for the release. You forgot to close the issue.