MOTION 2: Stop 2.x series support

[cvvergara]

Concept	value
Number	MOTION 2
Date of motion	October 2, 2020
Title	Stop 2.x series support
Mail Thread	pgRouting-dev
Result	Pass

name	Vote
Daniel	+0
Cayetano	+1
Regina	+1
Vicky	+1 (proposed by)
Rohith	No vote

I am opening this motion because its becoming too difficult to keep track of CGAL.

I found a bug [1] and when trying to fix for 2.6 there are problems.

I upgraded my system to focal, and now I am working on the issue fix.
I have no problems when fixing on the 3.x series (where CGAL dependency was removed).

For the 2.x (2.6.3) series there are issues:
2.6 uses CGAL and version 2.6.3 was released almost about a year and a half ago and CGAL might have changed in such a long time. Also compilers and C++ standards have evolved.
I have the routine of: before making a release to compile with 4.8 up to the current compiler version locally in my computer and there was no problem at that time with g++8.
and the code compiled with the -std=c++11 and -std=c++0x

Currently when compiling 2.6, with g++8 I am getting zillions of errors from CGAL of the following kind

/usr/include/CGAL/Kernel/hash_functions.h:25:13: error: ‘enable_if_t’ in namespace ‘std’ does not name a template type
 inline std::enable_if_t<std::is_same<typename K::Rep_tag, Cartesian_tag>::value, std::size_t>

To solve this compilation with CGAL implies a lot of work [3], [4]:

• figure out the exact version of CGAL to be used
• figure out any additional flags or the exact version of compiler to compile 2.6
• the changes will affect packagers of different operative systems, and they might or might not release a 2.6.4 because of big changes of requirements

We still have the 2.6 branch (2.6.3), available for updates but I think it will be easier to take the approach for the users:
"update to version 3"

Any way all the idea of having the version 3.0 on ward was to stop worrying about CGAL that needs GMP mpfr, which are three requirements in total for only one pgRouting function: pgr_alphaShape (that should be in GEOS/PostGIS as its a geometry function not a graph function).

If this motion gets approved:

• For pgRouting:
  • branch [2] release/2.6 would be deleted
  • No back porting of bugs fixes will take place to the version 2.6, in other words, 2.6.4 will never come out to life
• For pgRoutingLayer, the addition of new functionality will not consider 2.x versions of pgRouting
• Starting from PostgreSQL 13, Docker for 2.6.3 will not longer be needed to be created

references

• [1] Path evaluation on C++ not updated before the results go back to C pgrouting#1616
• [2] https://github.com/pgRouting/pgrouting/tree/release/2.6
• [3] https://stackoverflow.com/questions/58713496/error-using-libraries-provided-by-cgal-with-qt-creator
• [4] https://stackoverflow.com/questions/57074289/fixing-third-party-code-error-enable-if-in-namespace-std-does-not-name-a

[dkastl]

To be closed?