Mortar is pre-1.0. The first alpha has been published.
R25 published Java artifacts as 0.1.0-alpha.1, Rust crates as 0.1.0, and
the VS Code extension as 0.1.0 pre-release. Future releases must continue to
use guarded release automation and scoped publisher credentials.
Before 1.0.0:
- minor versions may include breaking API changes;
- patch versions should be compatible bug fixes;
- every breaking change requires migration notes that identify the affected artifact, package, type or property, replacement path, and automation status.
After 1.0.0, Mortar follows semantic versioning:
- MAJOR for incompatible API changes;
- MINOR for backwards-compatible functionality;
- PATCH for backwards-compatible bug fixes.
Before 1.0.0, Mortar treats these as public compatibility surfaces:
- Maven coordinates listed in this policy;
- handwritten Java public types in
dev.mortar.core,dev.mortar.jdbc,dev.mortar.postgres,dev.mortar.spring,dev.mortar.processor, anddev.mortar.testkit; - annotation names and annotation attributes used by the processor;
- generated
Q*naming conventions, generated table/column fields, generatedfindAll(renderer)andfindById(renderer)read facades, generated parameter records, and generated row records; - stable processor and core diagnostic codes;
- Spring Boot starter properties under
mortar.*; - Rust CLI command names and documented snapshot/report file formats.
Pre-1.0 minor releases may still change these surfaces, but every breaking
change must be listed in CHANGELOG.md and linked from release notes.
Current tested compatibility envelope:
- Java 25;
- Spring Boot 4.1.x for the starter;
- PostgreSQL 16 for PostgreSQL Testcontainers evidence;
- PostgreSQL as the only supported starter dialect;
- Rust stable toolchain for CLI/compiler/LSP crates.
Untested or future compatibility must not be described as supported in release notes, README, Maven metadata, or crate metadata.
Java artifacts use group io.github.sequelcore.
Public Java artifact IDs:
mortar-coremortar-dialect-postgresmortar-runtime-jdbcmortar-spring-boot-startermortar-processormortar-testkit
Publish only public Java libraries to Maven Central:
java:corejava:dialect-postgresjava:runtime-jdbcjava:spring-boot-starterjava:processorjava:testkit
Do not publish examples, benchmarks, aggregate projects, or editor plugins to Maven Central.
Rust crates use the sequel-mortar-* naming convention and publish in
dependency order:
sequel-mortar-compilersequel-mortar-clisequel-mortar-lsp
Before a public release:
docs/roadmap.mdis current.CHANGELOG.mdcontains user-visible changes.- Public API changes have migration notes.
- Architecture changes have ADRs.
- Java gates pass with
gradlew.bat check --no-daemon. - Rust gates pass with
cargo fmt,cargo clippy, andcargo test. - VS Code typecheck passes when the extension is included.
- Examples compile and tests pass.
- Maven local publication evidence exists.
- Central Portal validation or publication dry-run evidence exists for Java artifacts before any Maven Central publication.
- Cargo package inspection and dry-run evidence exists for publishable crates.
- Dependent Rust crates that cannot complete a crates.io publish dry-run until their internal dependencies are published have package-inspection evidence and a documented fail-closed reason.
- VS Code package dry-run evidence exists if the extension is included.
- Release automation uses scoped permissions, manual dispatch, protected environment gates, explicit confirmation, and runtime secret fetch before any upload step.
- Release notes are drafted from
CHANGELOG.md.
Maven local publication:
gradlew.bat publishToMavenLocal --no-daemon --no-configuration-cacheCargo package inspection and dry run:
cd rust
cargo package --list -p sequel-mortar-compiler
cargo package --list -p sequel-mortar-cli
cargo package --list -p sequel-mortar-lsp
cargo publish --dry-run -p sequel-mortar-compilersequel-mortar-cli and sequel-mortar-lsp depend on
sequel-mortar-compiler. Dry-runs for dependent crates should be repeated
after any compiler crate publication when dependency resolution behavior
matters for the release decision.
VS Code extension check:
cd editors/vscode
bun run typecheck
bun run package:check
bun run package:vsixpackage:check verifies the VSIX file allowlist and bundle-size budget.
package:vsix creates a local VSIX through the VS Code vsce package path. It
does not publish to the VS Code Marketplace.
Release automation is manual and guarded. The default workflow operation is
validate, which checks the release candidate without fetching publisher
credentials or uploading artifacts. Registry uploads require a separate
operation=publish workflow dispatch.
Publishing requires:
release_refequal tov<release_version>;confirmationequal topublish <release_version>;- at least one selected artifact family;
- the protected GitHub
releaseenvironment; - a repository
DOPPLER_TOKENsecret that can fetch release credentials from Doppler projectsequel-releases, configprd, at runtime.
The workflow does not publish on pushes, branch updates, pull requests, or tag creation. It does not create GitHub releases.
Maven Central publishing must use the current Central Portal path, validated POM metadata, sources, Javadocs, license metadata, SCM metadata, developer metadata, signatures, and CI-provided credentials.
Cargo publishing must inspect package contents before upload because published
crate versions are permanent and cannot be overwritten. Mortar publishes Rust
crates in dependency order: sequel-mortar-compiler, then
sequel-mortar-cli, then sequel-mortar-lsp.
VS Code extension publication requires the sequelcore Marketplace publisher,
a Marketplace PAT, and packaging evidence. The current workflow publishes with
the VS Code pre-release flag when the VS Code artifact family is selected.
Before any future publication action, verify:
- Sonatype Central namespace ownership, Central Portal token access, and signing credentials.
- crates.io owner access for the
sequel-mortar-*crates. - VS Code Marketplace publisher ownership for
sequelcoreand a Marketplace PAT if the extension is included. - Protected release controls for publication credentials, including branch protection or rulesets and a protected environment or equivalent approval gate.
- A release workflow
validaterun for the exact release tag before anypublishoperation.
Required Doppler release secrets:
MAVEN_USERNAMEMAVEN_PASSWORDGPG_PRIVATE_KEYGPG_PASSPHRASECARGO_REGISTRY_TOKENVSCE_PAT
The GitHub repository should store only the Doppler service token needed by the release workflow. Do not copy registry tokens, signing keys, or Marketplace PAT values into repository secrets, docs, logs, or prompts.
R25 published the first alpha. Future GitHub releases, announcements, stable version commitments, public performance claims, and application migrations require separate explicit decisions.