crankshaft/RELEASE.md

Release & Deployment Process

The release process of a new version of the extension shall be performed by the designated Release Manager.

Release steps

1. Make sure develop branch passes all the tests.
2. Merge develop into master
3. Update the version number in src/pg/crankshaft.control.
4. Generate the next release files with this command:

make release

1. Generate an upgrade path from the previous to the next release by copying the generated release file. E.g:

cp release/cranckshaft--X.Y.Z.sql release/cranckshaft--A.B.C--X.Y.Z.sql

NOTE: you can rely on this thanks to the compatibility checks.

TODO: automate this step #94

1. Commit and push the generated files.
2. Tag the release:

git tag -a X.Y.Z -m "Release X.Y.Z"
git push origin X.Y.Z

1. Deploy and test in staging
2. Deploy and test in production
3. Merge back into develop

Some remarks

• Version numbers shall follow Semantic Versioning 2.0.
• CI tests will take care of forward compatibility of the extension at postgres level.
• Major version changes (breaking forward compatibility) are a major event and are out of the scope of this doc. They shall be avoided as much as we can.
• We will go forward, never backwards. Generating upgrade paths automatically is easy and we'll rely on the CI checks for that.

Deploy commands

The new release can be deployed for staging/smoke tests with this command:

sudo make deploy

To install a specific version 'X.Y.Z' different from the default one:

sudo make deploy RELEASE_VERSION=X.Y.Z