-
Notifications
You must be signed in to change notification settings - Fork 1
Description
Problem
Now that we recommend committing versioned SQL files (e.g., sql/myext--1.2.0.sql), there's a window after a release where developers can accidentally commit changes to the released version file. If you release 1.2.0 and then keep working without bumping the version, your next make regenerates sql/myext--1.2.0.sql with new changes that weren't part of the 1.2.0 release.
Previously this wasn't an issue because versioned files weren't checked in — only upgrade files were. But with versioned files in git, the released version file must be frozen immediately after release.
Proposed solution
After tagging a release, the release process should immediately update default_version in the .control file to unstable. This:
- Makes it obvious you're on a development version
- Causes
maketo generatesql/myext--unstable.sqlinstead of overwriting the released file - The
unstableversioned file should be added to.gitignore(via_.gitignore) so it never gets committed
When you're ready for the next release, you update default_version to the actual new version number.
Note: unstable breaks semver, but PostgreSQL doesn't mandate semver for extension versions, so this is fine.
Changes needed
- Update
_.gitignoretemplate to ignoresql/*--unstable.sql - Update release process/skill to bump
default_versiontounstableafter tagging - Document the workflow in README