Future Planning and Refactoring

Vicky spent a lot of time looking into some of the details related to the work she has been doing with KSP and looking into differences with Dijkstra. She has a lot of good ideas and has identified a lot of issues with the code. Some are just bugs and some are areas where we can improve.

Add links to some examples

• [[Vicky's analysis of the Dijkstra et al and directed and has_reversecost flags|https://docs.google.com/document/d/1HagzIBHN-EV2S_n8_B3GaXC_O_IqiudKg-UMlBG_e-s/edit#]]

We need to try and organize stuff in one place it can be a google doc or wiki pages, but right now we parts of the discussion in Skype logs, chatwork, video conferences which are not logged, and in private email, and list email, etc, etc, etc. So starting this page to collect ideas, links, etc. to help define the problem and hopefully solutions that we can move forward with.

So to move this discussion forward, I'm thinking we need a framework for organizing the ideas. I would like to do this based on product releases like:

• pgRouting 2.0.x - bug fixes against current release
• pgRouting 2.x.x - features that do not break compatibility with 2.0
• pgRouting 3.x.x - major changes that might break compatibility
• pgRouting x.x.x - ideas for the future that may/may not get done

The KEY to the above releases is that:

• 2.0.x releases can not break command compatibility. Can not break existing commands except by fixing bugs. Really minor enhancements can be added to the release.

• 2.x.x releases can add major new functionality and fixes but can not break existing commands.

• 3.x.x releases are a major release with major new functionality. While we can restructure the existing commands and change their signatures if needed, we need to be mindful of the installed base.

• x.x.x release is just a placeholder for ideas that are nor scheduled for a release.

Then to continue using the Vicky's areas of needed improvement:

1. Directed and has_reversecost flags in Dijkstra and other functions
   1. error checking and reporting
   2. inconsistency in usage between commands
   3. elimination of these flags
2. Code sharing and reuse
   1. C code
   2. C++ code
   3. plpsql code
3. Int vs BigInt usage within commands
4. Boost and exposing more functionality

Each of these items have aspects that can be done in the above pgRouting releases. So we need to think through how to phase this work into the releases.

• Lets look at the bigint issue. this needs to be worked into the C++ code to do the renumbering and the C code needs to accept either int or bigint for node and edge ids. Because there are a lot of commands and it will be disruptive to the source and need a lot of testing it could be targeted for 2.x.x release.

• Error checking and reporting of directed and has_reversecost flags, could be done in 2.0.x, but might be better suited for 2.x.x release.

• Removing the directed and has_reverse cost flags this is a 3.x.x if we wanted to remove the old commands, but if we left the old commands there and just added new versions then this could be done in 2.x.x.

NOTE: yes we can add multiple versions of commands, BUT I'm a strong believer in keeping the release as minimal as possible and insuring that those commands are well tested. That means removing unneeded redundancy. We worked hard to do this in 2.0 and I don't want to see that undone.