Skip to content

MOTION 2: Stop 2.x series support

Jump to bottom
Vicky Vergara edited this page Oct 7, 2020 · 6 revisions
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

Maintained by the pgRouting Community
Website: https://pgrouting.org

Clone this wiki locally