• Developer steps 1 to 3 from how it works is transparent when doing a:

  cmake
  

original text: As a Developer, you do not need to do anything special when you are developing code. The system is automated and runs every time you cmake.

• Release Manager Before a release (step 4 of how it works): cp build/lib/pgrouting--<versions>.sig tools/sigs/pgrouting--<versions>.sig git add tools/sigs/pgrouting--<versions>.sig git commit -a -m 'Add the final version update signatures pgrouting--<versions>.sig' git push original text: If you are the Release Manager then you need to perform step 4. above as part of the release process. When you make the final release, the build/lib/pgrouting--<versions>.sig need to be copied and commited into the tools/sigs/ so it is available for future releases. I added this to the Release Plan Checklist.

We have a system to automatically track PostgreSQL FUNCTION and TYPE signatures so that pgRouting can automatically generate the files needed for ALTER EXTENSION pgrouting UPDATE to '<version>'. This system is mostly integrated into cmake and works like this.

1. we store signature files for old releases in tools/sigs/pgrouting--<version>.sig and these are used along with the current version to generate the update scripts.
2. when cmake is run it will create build/lib/pgrouting--<version>.sig for the current version using a perl script tools/mk-signature-file
3. cmake will also run tools/build-extension-update-files that will read all the files in tools/sigs/pgrouting--<versions>.sig and compare them to the current version and generate update script named build/lib/pgrouting--<old_version>--<current_version>.sql and these files will get installed appropriately with sudo make install.
4. when we do an official release, we need to also make sure the the final build/lib/pgrouting--<version>.sig also gets copied and committed into tools/sigs/pgrouting--<version>.sig so it will be available when we make the next release so we can generate update scripts for that.

• the current perl scripts mentioned above do not handle a TYPE definition change with the same TYPE name other than to throw an error.
• We do not check if the column name changes on for column types and this might be an issue.