Implement Automatic Version Numbering for postgkyl

Codex·GPT-6-astra·Maxwell-Rosen·yesterday·17min·1 Checkpoint·17 file changes·+597/-10·90K tokens

I'd like to have postgkyl's version number update automatically. So the version numbers go major_release.PR_number.commit. When the PR gets merged, the PR_number should go up. This starts with the current directory, which is pgkyl 2.0.0. Have this automatically maintained

yesterday·3.1s

I’ll check how Postgkyl currently sets its version and handles releases, then wire up automatic versioning from the 2.0.0 baseline.

I’m blocked before reading or changing files: the sandbox fails to start because its read-only rule for .codex conflicts with that directory being a symlink. Even commands from /tmp fail.

Please fix that sandbox configuration and retry. No files have changed.

I’ll interpret your scheme as 2.<merged-PR count>.<commits since last merge>: start at 2.0.0, increment the last component for commits, and increment the middle component and reset the last to zero when a PR merges.

I'd like to have postgkyl's version number update automatically. So the version numbers go major_release.PR_number.commit. When the PR gets merged, the PR_number should go up. This starts with the current directory, which is pgkyl 2.0.0. Have this automatically maintained

yesterday·4.2s

I’ll implement this from the 2.0.0 baseline, using the middle number as a merged-PR counter and the last number as commits since that release. I’m applying the Postgkyl design and development skills while checking the existing packaging and workflows.

Actually, I'd like to do major_release.minor_release.PR_number.commit. Putting minor releases in there helps with small version releases

yesterday·20.3s

I’ll use major.minor.PR.commit, starting at 2.0.0.0. Merging a PR will increment the third number and reset the commit count; an explicit minor release will reset both trailing numbers. I’ll make the package metadata and pgkyl --version use the same source.

The version is currently hardcoded, and this checkout is on a feature branch. I’ll use release tags to record merged-PR increments and Git history to count subsequent commits. The automation will catch up on missed merges, while built wheels will retain their version without needing Git.

The four-part version and merge-tagging workflow are in place. I’m checking commit counting, minor/major resets, rerun safety, and version preservation in wheels and source distributions. I’m also testing the initial squash merge, since it can remove this feature branch’s baseline commit from main’s history.

The artifact check passed: the sdist, rebuilt wheel, installed metadata, and CLI all report 2.0.0.0 without Git. Formatting and lint checks also pass. Main-branch CI now waits for version tagging before building packages; the full test suite is still running.

The full suite passed: 2,018 tests, with 6 skips. The final versioning and packaging checks also passed, including first-time merge, squash, and rebase histories. I’m finishing the documentation check and its navigation update.

The documentation build and updated navigation check passed. The remaining check runs the downloadable examples. Once these changes reach main, PR increments will run automatically; the Version workflow will also let you request minor and major releases.

Implemented major.minor.PR.commit, starting at 2.0.0.0.

  • Commits increment the fourth number.
  • Merged PRs increment the third and reset commits.
  • The Version workflow supports minor/major releases.
  • Package metadata and CLI versions stay consistent.

Automation activates when merged into main.

Validation: full suite passed (2,018 tests), plus final versioning, packaging, documentation, and lint checks.