Version Update Signatures

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.

What Do YOU need to do?

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.

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.

ISSUES and LIMITATIONS

• 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.