Skip to content

Post-release workflow: immediately bump default_version to 'unstable' #20

@jnasbyupgrade

Description

@jnasbyupgrade

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:

  1. Makes it obvious you're on a development version
  2. Causes make to generate sql/myext--unstable.sql instead of overwriting the released file
  3. The unstable versioned 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 _.gitignore template to ignore sql/*--unstable.sql
  • Update release process/skill to bump default_version to unstable after tagging
  • Document the workflow in README

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions