The release process of a new version of the extension shall be performed by the designated Release Manager.
- Make sure
develop
branch passes all the tests. - Merge
develop
intomaster
- Update the version number in
src/pg/crankshaft.control
. - Generate the next release files with this command:
make release
- Generate an upgrade path from the previous to the next release by copying the generated release file. E.g:
cp release/crankshaft--X.Y.Z.sql release/crankshaft--A.B.C--X.Y.Z.sql
NOTE: you can rely on this thanks to the compatibility checks.
TODO: automate this step #94 2. Update the NEWS.md file
- Commit and push the generated files.
- Tag the release:
git tag -a X.Y.Z -m "Release X.Y.Z"
git push origin X.Y.Z
- Deploy and test in staging
- Deploy and test in production
- Merge back into develop
- 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.
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