fix(release-automation): scope publishability to polars-free crates (R6 deviation row 5 — Path A)#155
Merged
githubrobbi merged 2 commits intomainfrom May 8, 2026
Conversation
…ty:`
Brings forward the Phase R1b "decide whether to keep top-level
`security:` or migrate to `chore(security):`" sub-question and resolves
it: top-level `security:` is no longer an accepted Conventional Commits
type anywhere in the toolchain. Security work uses `fix(security):`
(patch + Security changelog row) or `chore(security):` (no bump +
Security changelog row).
Background — four regexes had drifted into two camps:
Strict (11 standard CC types):
- scripts/ci/check_commit_subjects.sh (commit-msg + pre-push hook)
- .github/workflows/commitlint.yml (PR-title advisory check)
Permissive (11 + top-level `security:`):
- cliff.toml::commit_parsers
- release-plz.toml::release_commits
The permissive carve-out tolerated PRs #31, #33, #34 — three early-
project commits that used `security:` as a top-level type before the
commit-msg hook was installed. Since the hook landed, no future commit
can use that prefix on `main`, so the cliff.toml + release-plz.toml
allowances are dead code preemptively allowing what no longer reaches
the codebase. The dedicated `^fix\(security\)` and `^chore\(security\)`
parsers in `cliff.toml` already route security work to the dedicated
**### Security** changelog section without the top-level type.
Changes:
- `release-plz.toml::release_commits`:
^(feat|fix|perf|security)(\\(.+\\))?:
→ ^(feat|fix|perf)(\\(.+\\))?:
Plus a comment block explaining the security-encoding convention
and pointing to CONTRIBUTING.md.
- `cliff.toml::commit_parsers`:
Drop the `^security(\\([a-z0-9-]+\\))?:` line and its carve-out
comment. The two scope-based parsers
(`^fix\\(security\\)` + `^chore\\(security\\)`) remain, so the
Security changelog section is unaffected.
- `CONTRIBUTING.md` § "Commit message conventions":
Add a "Security commits" paragraph explicitly codifying
`fix(security):` + `chore(security):` as the canonical encodings
and stating that top-level `security:` is NOT an allowed type.
Cross-reference the commit-msg hook + commitlint workflow + the
release-plz `release_commits` filter.
- `docs/architecture/release-automation-plan.md`:
Append a deviation log entry "R1b CC-type convergence (early)"
documenting the decision, the dead-code rationale, and that
historical PRs #31/#33/#34 remain in the changelog.
No code changes. Pure regex + comment + docs convergence.
Validation:
- `git grep -nE "release_commits|\\^security|security:"` in
`cliff.toml` + `release-plz.toml` shows the four regexes now
agree (11 standard CC types only).
- No CHANGELOG churn — the historical PR #31/#33/#34 entries are
not regenerated by `git-cliff` because they predate the most
recent tag.
- `taplo fmt --check` on the two TOML files green.
Refs: #153 (R5 retirement, where the drift was first surfaced).
Plan impact: brings R1b's enforcement decision forward by ~1 phase.
Does NOT change the R1a → R1b advisory→required scheduling for the
commitlint workflow itself; only resolves the orthogonal type-list
sub-question.
…R6→R8 deviation row 5 — Path A)
Resolves the `release-plz-pr` job hard-failing on every push to `main`
with `failed to select a version for chrono` from the polars subtree's
`cargo package` step. See `docs/architecture/release-automation-plan.md`
deviation log row "R6 → R8 publishability resolution (Path A)" for the
full diagnostic trail.
TL;DR root cause:
polars git/rev pin → polars-arrow declares chrono ^0.4.42
crates.io polars 0.53.0 → polars-arrow declares chrono <=0.4.41
These are mutually exclusive — no chrono version satisfies both.
`cargo package` strips the git rev (publishing simulation) and
falls back to crates.io polars 0.53.0; the conflict surfaces on
every release-plz invocation.
Why not "drop the git rev" (Path B-i)?
Probed on 2026-05-08. Crates.io polars 0.53.0 has accumulated
multiple nightly-rust-API regressions that the in-workspace git rev
actively patches:
- polars-arrow-0.53.0/src/bitmap/bitmask.rs:2 →
`std::simd::{LaneCount, SupportedLaneCount}` shapes don't exist
in current nightly (`nightly-2026-05-08`).
- polars-ops-0.53.0/src/chunked_array/strings/case.rs:79 →
`core::unicode::{Case_Ignorable, Cased}` (Cased missing,
Case_Ignorable private).
Dropping the git rev breaks `cargo build --workspace`. The git rev
is load-bearing, not opportunistic. Path B-i abandoned.
What this PR does (Path A):
1. Adds `publish = false` to the 8 polars-tainted crates' Cargo.toml:
- uffs-polars (direct polars dep — root of the subtree)
- uffs-mft (direct uffs-polars dep, ~28 import sites)
- uffs-format (transitive via uffs-mft)
- uffs-core (direct + transitive, ~54 import sites)
- uffs-daemon (transitive via uffs-mft + uffs-core)
- uffs-client (transitive via uffs-format → uffs-mft)
- uffs-mcp (transitive via uffs-client → …)
- uffs-cli (transitive via uffs-client + uffs-format → …)
Each crate's comment block explains its specific role in the
subtree and points at the deviation log row.
2. Updates `release-plz.toml`: replaces the 8 corresponding
`[[package]] changelog_path = "CHANGELOG.md"` blocks with
`release = false` so release-plz skips them entirely (no version
bump computation, no `cargo package` step at all). The 4 polars-
free crates (`uffs-time`, `uffs-text`, `uffs-security`,
`uffs-broker`) keep their `changelog_path` entries and remain
release-eligible.
3. Updates `crates-io-dry-run.yml` doc-comments: the workflow's jq
filter (`select(.publish != [])`) already skips publish=false
crates automatically, so no logic change needed; the header
comments are refreshed to mark the polars/chrono known-expected
failure as RESOLVED.
4. Appends a new deviation log row to release-automation-plan.md
§8 documenting the probe-and-pivot trail and the re-enable
procedure (5 steps, all reversible) for when polars upstream
publishes a release containing the nightly-API patches.
Verification:
- `cargo build --workspace` ✓ (1m 40s, post-changes)
- `cargo package -p uffs-time --no-verify --allow-dirty` ✓
(representative polars-free crate)
- `cargo metadata` jq partition matches expectation:
publishable (4): uffs-broker, uffs-security, uffs-text, uffs-time
non-publishable (12): 8 newly-tagged + 4 pre-existing internal
tools (uffs-ci-pipeline, uffs-diag,
uffs-gen-hooks, uffs-gen-workflow)
Plan impact:
- R6 PARTIALLY RESOLVED — publishability invariant scoped to 4 of
12 originally-publishable crates.
- R7 (OIDC scaffolding) unaffected — the dormancy gate doesn't care
which crates are publishable.
- R8 dress rehearsal still feasible on its originally-chosen leaf
target `uffs-time` (polars-free).
- R9 (full publish) DEFERRED until polars upstream ships a
compatible release; track via `crates-io-dry-run.yml` weekly.
End-user impact:
- `cargo install uffs-cli` is now blocked. `just use` (GitHub
Releases tarball install — the recommended path) is unaffected.
- Daily development workflows (`cargo build`, `cargo test`,
`just ship`, `just use`) all work unchanged.
Refs: deviation log row "R6 → R8 publishability resolution (Path A)"
in docs/architecture/release-automation-plan.md
githubrobbi
added a commit
that referenced
this pull request
May 8, 2026
…ft types (#156) The `pub use uffs_polars::{DataFrame, IntoLazy, LazyFrame, col, columns, lit}` and `pub use uffs_mft::FileFlags` re-export blocks in `crates/uffs-core/src/lib.rs` had ZERO downstream consumers (verified via repo-wide grep — no .rs file outside uffs-core itself imports any of these symbols via `uffs_core::*`). They were leftover from before the C6.* migration in 2026-Q1 that moved all consumers off the `uffs_core::` re-export aliases onto direct `uffs-polars` / `uffs-mft` imports. This commit: - deletes both dead re-export lines; - refreshes the surrounding comment block to explain why `CaseFold` is the only remaining cross-crate re-export through `uffs-core` and why polars types are deliberately NOT re-exported here. Why now: PR #155 (the R6→R8 publishability resolution Path A — see deviation log row in `docs/architecture/release-automation-plan.md`) flipped `uffs-polars` to `publish = false` and called for the polars-tainted dep graph to be explicit at the Cargo.toml level. Dead re-exports of polars types through `uffs-core` muddied that contract: a future contributor reading `uffs_core::DataFrame` might assume polars APIs are part of uffs-core's public surface. Removing the dead code makes the "consumers must depend on `uffs-polars` directly" rule visible at the source. Verification: - `cargo check --workspace --all-targets` succeeds (no consumer broke) — completed in 34.26s. - Repo-wide grep before deletion: `uffs_core::(DataFrame|LazyFrame|IntoLazy|columns|FileFlags)\b` `use uffs_core::\{[^}]*\b(DataFrame|LazyFrame|IntoLazy|columns|col|lit|FileFlags)\b` Both empty. Plan impact: none. `uffs-core` is `publish = false` (PR #155, R6→R8 deviation), so the public-API surface change has no external consumer. The 4 polars-free crates (`uffs-time`, `uffs-text`, `uffs-security`, `uffs-broker`) are unaffected. This commit is `refactor:` (no behavior change), so release-plz won't trigger a version bump from it (matches `release_commits = "^(feat|fix|perf)(\\(.+\\))?:"` in `release-plz.toml`). Refs: PR #155 (R6→R8 publishability resolution Path A); deviation log row "R6 → R8 publishability resolution (Path A)" in `docs/architecture/release-automation-plan.md` §8.
githubrobbi
added a commit
that referenced
this pull request
May 9, 2026
…s upstream ships chrono-compat release (#157) PR #155 (R6→R8 publishability resolution Path A) flipped the eight polars-tainted crates (`uffs-polars`, `uffs-mft`, `uffs-format`, `uffs-core`, `uffs-daemon`, `uffs-client`, `uffs-mcp`, `uffs-cli`) to `publish = false` + `release = false`, expecting that to make release-plz skip them in its workspace iteration. Workflow run 25583934251 on commit `d3a1adc1d` (the PR #155 merge) proved Path A insufficient: release-plz still tried to package `uffs-polars` and failed with the chrono ≤0.4.41 vs 0.4.44 conflict. Root cause (verified by reading `release-plz` v0.3.157 source on 2026-05-08): release_plz_core/src/next_ver.rs::run_cargo_package — in `git_only = true` mode (which we use because UFFS isn't yet on crates.io) release-plz hardcodes cargo package --allow-dirty --workspace per package being processed. That step packages EVERY workspace member regardless of `[[package]] release = false` or Cargo `publish = false` flags. When it runs against `uffs-polars`, cargo strips the polars git-rev pin for publish-form simulation, falls back to crates.io `polars-arrow 0.53.0` which constrains `chrono <= 0.4.41`, and that conflicts with the workspace lock at `chrono 0.4.44` (transitively required by `chrono-tz 0.10.4`). No combination of release-plz config flags avoids this. Fix options considered: (A) Move `crates/uffs-polars` from `[workspace] members` to `[workspace] exclude`. Removes it from `cargo metadata --workspace`, which is the set release-plz iterates. Cost: cargo treats excluded paths as standalone packages, so uffs-polars's nine `.workspace = true` inheritances (version, edition, rust-version, license, repository, authors, readme, keywords, categories) plus `[lints] workspace = true` all break and must be inlined. Permanent maintenance burden until uffs-polars rejoins the workspace. Rejected. (B) Replace `release-plz/action` with manual CLI invocation that wraps the cargo step ourselves. Out of scope for the current release-automation refactor cycle (R5 just finished; R6/R7 already in flight). Rejected for now. (C) [chosen] Defer the release-plz auto-trigger. Comment out `push: branches: [main]`; keep `workflow_dispatch:` so the maintainer can spot-check what release-plz proposes manually (e.g. on a temporary branch where the polars rev is bumped, ahead of formally re-enabling). Until polars upstream ships a release that no longer needs the git rev pin, version bumps continue via the existing `just ship` flow (delegates to the `uffs-ci-pipeline` crate's `ship` subcommand) which has been the canonical manual mechanism since v0.5.0. Changes in this commit: - Workflow renamed: "🚀 Release-plz (active)" → "💤 Release-plz (deferred — manual-only)" so the dormant state is visible from the GitHub Actions UI. - `push: branches: [main]` block commented out with a clear inline comment explaining when to uncomment. - `workflow_dispatch:` retained as the only active trigger. - Header comment block restructured to lead with a "DEFERRAL NOTICE (2026-05-08)" section that captures the root cause, the two rejected fix paths, the manual `just ship` workflow, and the four steps to re-enable when polars upstream ships. What stays unchanged: - PR #155's `publish = false` flips on the eight polars-tainted crates remain in place — they are still the correct intent (those crates legitimately cannot ship to crates.io until the polars rev pin can be retired). This commit just acknowledges that those flags don't suffice to make release-plz green. - PR #155's `release = false` entries in `release-plz.toml` likewise stay — they correctly suppress release/PR/tag/changelog actions for those crates, which is the only thing the flag actually controls. - The `release-plz/action` pin and the rest of the workflow (jobs, permissions, downstream-trigger bridge) are untouched so re-enabling is a one-line uncomment of the `push:` block. Re-enable trail (also captured inline in the workflow YAML): 1. Verify `cargo package -p uffs-polars --allow-dirty` succeeds locally (it should once polars upstream ships a chrono-compat release). 2. Uncomment the `push: branches: [main]` block. 3. Optionally reverse the `publish = false` flips on the eight polars-tainted crates if R8 dress-rehearsal is ready. 4. Rename the workflow back to "🚀 Release-plz (active)". Refs: - PR #155 (R6→R8 Path A) — set up the publish=false flags this commit acknowledges as insufficient. - Workflow run 25583934251 — failure evidence (chrono conflict). - `release_plz_core/src/next_ver.rs::run_cargo_package` — root-cause source (release-plz v0.3.157). - `docs/architecture/release-automation-plan.md` §8 deviation log row "R6 → R8 publishability resolution (Path A)" — the audit trail this commit extends. - `just/workflow.just` `ship` recipe — the manual flow that keeps version bumps moving while release-plz is dormant.
githubrobbi
added a commit
that referenced
this pull request
May 9, 2026
…mp tooling (#158) Reverts the deletions in PR #153 (commit 779c14f) so the local `just ship` flow has a working version-bump path again. The R5 landing made the bespoke flow disappear on the same day that PR #157 deferred release-plz's `push: branches: [main]` auto-trigger (release-plz cannot `cargo package --workspace` past the chrono ≤0.4.41 vs 0.4.44 conflict that comes from our git-pinned polars rev). Combined effect: zero working version-bump driver. `just ship-fresh` failed at step `10-git-commit` with 'nothing to commit, working tree clean' because no step bumped the workspace version anymore. Restored: - `build/update_all_versions.rs` (1073 LOC) — bespoke workspace bumper. - `scripts/ci/ci-pipeline.rs` (53 LOC) — Phase 7 deprecation shim. - `increment_version` + `version_bump` fns in `scripts/ci-pipeline/src/version.rs`. - `STEP_VERSION_INCREMENT` + `WorkflowPhase::VersionIncrementing` + its membership in `ALL_STEPS` in `scripts/ci-pipeline/src/workflow.rs`. - Version-bump step in `run_enhanced_phase2` (ship.rs) and `phase2_optimized` (phases.rs). - `version-bump` recipe in `just/build.just`. - Version-bump step in `quick-deploy` recipe (`just/dev.just`). - `!build/update_all_versions.rs` carve-out in `.gitignore`. - R5's pre-merge docstrings in version.rs/workflow.rs/ship.rs/phases.rs describing the bespoke bumper as the canonical driver. Kept deleted (operator decision — Option 3 of the rollback plan): - `.github/workflows/auto-tag-release.yml`. `release-plz.yml` retains the dormant `gh workflow run release.yml` bridge step that R5 added; combined with `release.yml`'s native `on: push: tags: [v*]` trigger, tag→build dispatch is covered when the maintainer pushes a signed tag manually after a `just ship` cycle merges. Resurrecting auto-tag-release.yml would add a third dispatcher for no benefit. Preserved post-R5 work: - PR #154 (CC-regex convergence in cliff.toml + release-plz.toml). - PR #155 (`publish = false` + `release = false` flips on the 8 polars-tainted crates: uffs-polars, uffs-mft, uffs-format, uffs-core, uffs-daemon, uffs-client, uffs-mcp, uffs-cli). - PR #156 (uffs-core dead re-exports removed). - PR #157 (release-plz workflow renamed to '💤 Release-plz (deferred — manual-only)' with `push: branches: [main]` commented out and `workflow_dispatch:` retained as the only active trigger; release-plz remains dormant). Conflict resolution: - Single conflict in `docs/architecture/release-automation-plan.md` (deviation log). Resolved by keeping HEAD's rows (the post-R5 deviation entries describe historical facts that happened on 2026-05-08; they stay as the audit trail) and appending a new `R5 rollback (polars-upstream wait)` row that documents this PR. The R5 dashboard row at line 2031 flips from ⬜ (post-revert pre-R5 state) to 🔴 ROLLBACK with a pointer to the deviation row. Validation: - `cargo check -p uffs-ci-pipeline --locked` green. - `cargo clippy -p uffs-ci-pipeline --locked --all-targets -- -D warnings` green. - `cargo fmt --all -- --check` green. - `actionlint .github/workflows/release-cache-warm.yml .github/workflows/release-plz.yml` green. - `grep '<<<<<<<\|=======\|>>>>>>>' docs/architecture/release-automation-plan.md` returns 0 matches. Re-application path: When polars upstream ships a chrono-compat release that lets `cargo package -p uffs-polars` succeed end-to-end, R5 can be re-applied as a single forward PR: re-delete the same files this revert restores, re-add `STEP_VERSION_INCREMENT` to ALL_STEPS, uncomment `push: branches: [main]` in `release-plz.yml`, optionally re-delete `auto-tag-release.yml` (which this rollback already keeps deleted). The `release-plz.yml` bridge step is already in place and dormant; the only flip needed is the trigger. Refs: - PR #153 (R5 — retire bespoke version-bump tooling) — reverted here. - PR #157 (release-plz auto-trigger deferral) — preserved. - `docs/architecture/release-automation-plan.md` §8.1 — new deviation row `R5 rollback (polars-upstream wait)`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two release-automation-hardening commits, bundled because they share scope (
release-plz.tomledits) and goal (unblock release-plz onmain):b81f5d5b8—fix(release-automation): converge CC regexes — drop top-level security:(preexisting commit on this branch)c48601e5e—fix(release-automation): scope publishability to polars-free crates (R6→R8 deviation row 5 — Path A)(this PR's main contribution)Why this PR
release-plz-prhas been hard-failing on every push tomainsince the R4 active-mode landing (PR #149) withfailed to select a version for chronofrom the polars subtree'scargo packagestep. Documented indocs/architecture/release-automation-plan.mddeviation log row "R6 → R8 publishability" (2026-05-07) as a known issue with two proposed resolutions: (a)publish = falseon the polars subtree, or (b) align chrono with crates.io polars expectations.This PR executes (a). Path B-i was probed and abandoned — see deviation log row "R6 → R8 publishability resolution (Path A)" (2026-05-08) for the full trail.
Root cause (one sentence)
The polars
git/revpin'spolars-arrowdeclareschrono ^0.4.42, while the publishedpolars-arrow 0.53.0declareschrono <=0.4.41— same version number, mutually exclusive constraints, no chrono version satisfies both, and the git rev is load-bearing for nightly compatibility so it cannot be dropped.What's in commit
c48601e5e(Path A)publish = falseon 8 polars-tainted cratesuffs-polarsuffs-mftuffs-polars.workspace = true)uffs-formatuffs-mftuffs-coreuffs-daemonuffs-mft+uffs-coreuffs-clientuffs-format → uffs-mftuffs-mcpuffs-client → …uffs-cliuffs-client + uffs-format → …Each crate's Cargo.toml gets a comment block explaining its specific role and pointing at the deviation log row.
release = falseon the same 8 crates inrelease-plz.tomlReplaces the corresponding
[[package]] changelog_path = "CHANGELOG.md"blocks. release-plz now skips those crates entirely (no version bump, nocargo packagestep). The 4 polars-free crates (uffs-time,uffs-text,uffs-security,uffs-broker) keepchangelog_pathand remain release-eligible.crates-io-dry-run.ymldoc-comment refreshThe workflow's
cargo metadata | jq 'select(.publish != [])'enumeration filter already skips publish=false crates, so no logic change needed; just updates the header doc-comments to mark the polars/chrono known-failure as RESOLVED.Deviation log row appended
Documents the probe-and-pivot trail (Path B-i discovery → Path A execution) and the 5-step re-enable procedure for when polars upstream publishes a release with the nightly-API patches.
Verification
crates-io-dry-run.ymlwill now dry-run only those 4 crates on its weekly cadence; the previously-known polars/chrono failure no longer surfaces.Plan impact
uffs-time(polars-free).End-user impact
cargo install uffs-cliis now blocked.just use(GitHub Releases tarball install — the recommended path) is unaffected.cargo build,cargo test,just ship,just use) work unchanged.feat:/fix:/perf:commit tomainshould successfully open arelease-plz-vX.Y.ZPR for the 4 publishable crates (proving R5 → R4 graduation is unblocked).Reversibility
Fully reversible in 5 steps when polars upstream publishes a fix (documented in the deviation log row):
publish = false→ unset in the affected Cargo.toml files.release = false→changelog_path = "CHANGELOG.md"inrelease-plz.toml.git/revpin incrates/uffs-polars/Cargo.tomlin favor of the new published version.chrono = "=0.4.41"(likely loosen if upstream relaxes).just polarsrecipe.Refs
docs/architecture/release-automation-plan.mdrows "R6 → R8 publishability" (2026-05-07) and "R6 → R8 publishability resolution (Path A)" (2026-05-08).crates/uffs-polars/Cargo.tomlheader comment block — full diagnostic narrative.