From @tfoote in #160 (comment):

I'd like to revisit the discussion for OpenCV. In particular we updated targets for everything to be 3.4 in #139 In particular comments at #139 (review) #139 (review)

We only pushed ahead to 3.3 based on this request: https://discourse.ros.org/t/opencv-3-3/2674 and that upgrade caused significant issues and debugging time. And we've had several request to fall back to 3.2 during the process. We thought that the new release would be fully backwards compatible but it was not and with the knowledge that I have now, I would have not chosen to make the upgrade if I could choose again.

With 3.2 available for our LTS platform (bionic) and 3.1 on the soon to be EOL'd platform (artful) the only major outlier is that stretch is older and only has 2.4.9.

I'd like to suggest that we fall back to using the system dependencies again instead of packaging OpenCV within ROS packages. On most of our platforms we're within a minor release.

To make things close to compatible I would propose that we backport buster's 3.2 to stretch, and then by July we'll only need to support 3.2 or higher. Which I believe is already available in Fedora and other platforms. And if there's something major blocking on Artful's 3.1 we could backport bionic's 3.2 or blacklist opencv3 on artful as it's very close to EOL.

There are significant advantages to using the upstream packages. In particular we are compatible with other system dependencies that rely on the system opencv installation. There are also standard replacement packages that enable hardware acceleration for systems with CUDA, Neon, etc maintained by the greater community. This would allow ROS users to leverage those builds.

We will also avoid significant build time on the ROS buildfarm, as well as maintaining a parallel custom package which has cost us a lot of time in this last cycle. In the past there's been issues with contrib not being available and the opencv version upstream being very out of date. Also as there's now the same major version of opencv on most platforms we need to be much more careful about declaring conflicts and making sure that our installation and the system one do not collide.

If people really do need to have the latest and greatest version of opencv, replacing the system version is relatively straight forward, it will just require that that any package depending on the custom version of opencv be compile from source. This is standard development processes, and with recent containerization technologies can even be relatively easily shared and reproduced.

I know that there are people that are strongly pushing for the bleeding edge latest things, but a large part of being in a distro is to be stable and solid for those not pushing the envelope. The new features will become available, but to provide the stability of a distro I think that we should not try to significantly push ahead of the upstream packaging.

@mikaelarguedas @vrabaud @clalancette

Follow-up from @clalancette:

I'm totally fine with this, as I agree the benefits of sticking to the system packages outweigh the benefits of having a newer package available. I'd even go further and suggest that we make sure to stick with whatever version we choose for the lifetime of the distribution, to make sure we don't have a repeat of what happened with OpenCV 3.3.

That all being said, I'm not one of the bleeding edge users that really want newer OpenCV features, so I'd like to hear from @vrabaud before we change this.