Contribution

This page collects contributor-facing build, testing, and release notes. The README stays focused on project capabilities, quick installation, and user entry points.

Build From Source

Build the extension with the PostgreSQL development files for the target PostgreSQL major installed:

make
make install
make installcheck

If pg_config is not on PATH, pass it explicitly:

make PG_CONFIG=/path/to/pg_config
make install PG_CONFIG=/path/to/pg_config
make installcheck PG_CONFIG=/path/to/pg_config

After installation, create the extension in a target database:

CREATE EXTENSION psql_bm25s;

If you need a non-public extension schema, choose it when creating the extension:

CREATE EXTENSION psql_bm25s WITH SCHEMA ext;

The extension is not relocatable after creation because SQL helper functions capture the extension schema for safe wrapper resolution.

Testing

The main local validation entry points are:

ctest --test-dir build_tmp --output-on-failure
make installcheck

Current validation coverage includes:

• standalone unit tests
• PostgreSQL pg_regress integration tests
• maintenance-state and policy regression coverage
• restart smoke
• crash-recovery smoke
• physical-replication smoke
• concurrent maintenance stability smoke and broader stress runs

For the full test matrix, smoke scripts, schema-upgrade checks, hybrid-search coverage, and benchmark validation gates, see Testing and Validation.

Release Automation

Current release line:

• extension version: read default_version from psql_bm25s.control
• supported release targets:
  • PostgreSQL 17
  • PostgreSQL 18
  • Docker image based on official postgres:18
• release artifact formats:
  • .zip
  • GitHub Packages container image at ghcr.io/intelligent-internet/psql_bm25s

Automation model:

• pushes and pull requests build and test on GitHub Actions
• versioned releases are created from Git tags such as vX.Y.Z
• GitHub Releases use autogenerated release notes based on commits since the previous tag
• release assets are built per PostgreSQL major and uploaded as zip packages plus checksum files
• each release also publishes a PostgreSQL 18 Docker image to GitHub Packages

Current workflows:

• CI
  • runs on push to main, push to release, and on pull requests
  • builds and tests PostgreSQL 17 and 18
  • builds and smoke-tests the PostgreSQL 18 Docker image without publishing it
• Release
  • runs on tag push matching v*
  • rebuilds, retests, packages, publishes a GitHub Release, and pushes the versioned PostgreSQL 18 Docker image to GitHub Packages
• Prepare Release
  • runs automatically on normal pushes to the release branch
  • skips the first branch-creation push and bot-authored version-bump pushes
  • can still be run manually with an optional major.minor series such as 0.4
  • auto-increments the patch version, updates extension version files, commits the bump to release, creates the tag, pushes it, and dispatches the Release workflow

The intended release practice is:

1. Merge validated changes to main.
2. Fast-forward or merge main into release.
3. Let Prepare Release bump the next patch version on release and dispatch Release.
4. Let Release publish vX.Y.Z packages and Docker images.

Detailed benchmark evidence and release-readiness checks should link to Performance and Benchmarks and Testing and Validation rather than duplicating their contents here.