Hi Cayetano
Please Merge first the branch to “develop” branch.
And clean the repository
send a mail to this list about the branches that will be deleted,
wait 3 or 4 days for people to double check that no “important” work will be deleted.
Make sure that the tag that contains the GSoC students work was created.
(and the tag has as last commit, the last commit of the student during the program)
I really don’t remember if I taged his work, we never continue work on a students branch,
that branch has to remain intact when the GoC program is over that contains the students work and his work only.
By cleaning the repo:
When people clone or update their fork, they would only get master and develop branch.
master has pgRoutingLayer v2.2.0 and branch develop has v3.0.0-dev
Because the version is a “major” change we have to go thru the following phases:
v3.0.0-alpha (v3.0.0-alpha1 if needed see bellow)
v3.0.0-beta
v3.0.0-rc
etc.
Use that versioning numbering to create the following branches & tags
v3.0.0-alpha1 Includes all the functions that are coded
v3.0.0-alpha2 Remove function(s) that is(are) well-known to have issues (issues must be documented on the issue list)
or
v3.0.0-alpha Include only the functions that supposedly work well
or
v3.0.0-alpha1 Includes only pgr_dijkstra
v3.0.0-alpha2 Includes also pgr_dijkstraCost
etc …
I like third option best because also work on documentation has to be done.
So make users documentation of pgr_dijkstra and make the alpha with only that function
So gradually documentation and functionality come in an alpha
I know version pgRoutingLayer v3.0.0 will use python3 what I dont know, is which versions of QGIS it will work.
The version v2.0 didn’t handle the functions with the “pgr_” is that going to remain the same?
Which versions of pgRouting will it work with?
I guess you removed all the deprecated functions, so for example, and kept for example
for 2.1: pgr_dijkstra, pgr_drivingDistance and pgr_KSP
Maybe, many users (like me) have QGIS 2.18
Some instructions about testing the phases would be needed.
About initial decisions of what can be included:
Now that we are starting a new major
one thing is I learned is don’t include what does not work
In our case, besides pgRoutingLayer code correctness, we depend on the correctness of pgRouting :
About withPoints & all proposed functions
https://docs.pgrouting.org/2.6/en/proposed.html#stable
There is a warning. and some detected issues:
https://github.com/pgRouting/pgrouting/issues?q=is%3Aopen+is%3Aissue+label%3AwithPoints
About experimental functions:
https://docs.pgrouting.org/2.6/en/proposed.html#experimental-functions
About pgr_dijkstraCost in QGiS I use it (to generate the image) here:
https://workshop.pgrouting.org/2.5.0/en/chapters/shortest_path.html#exercise-5-many-pedestrians-going-to-different-destinations-returning-aggregate-costs
compare VS
https://workshop.pgrouting.org/2.5.0/en/chapters/shortest_path.html#exercise-4-many-pedestrians-going-to-different-destinations
It gives a different perspective of the results of pgr_dijkstra
As reference:
This is the latest pgRouting documentation
https://docs.pgrouting.org/2.6/en/index.htm
This is the pgRouting 3.0.0-dev documentation (to be released on September 2019)
https://docs.pgrouting.org/dev/en/index.html
Lots of things to plan
Regards
Vicky
···
Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44,
81739 München, Germany
Vicky Vergara
Operations Research
eMail: vicky@[georepublic.de](http://georepublic.de)
Web: [https://georepublic.info](https://georepublic.info)
Tel: +49 (089) 4161 7698-1
Fax: +49 (089) 4161 7698-9
Commercial register: Amtsgericht München, HRB 181428
CEO: Daniel Kastl
