chore(release): bump library crates in lockstep with binary (FJ-20) #19

Merged

David merged 3 commits from chore/create-release-bump-libs-lockstep-fj-20 into main

2026-05-28 10:02:27 +02:00

David commented

2026-05-28 04:11:04 +02:00

Owner

Summary

Fixes the create-release recipe so all three workspace crates move in lockstep. Previously the recipe computed and wrote the bumped version only into crates/fj/Cargo.toml (package forgejo-cli) and staged only that file, leaving fj-client and fj-core stranded at 0.5.0 while the binary advanced to 0.6.0.

Change

In justfile create-release, the version-write step now applies the update package.version $bare transform to crates/fj/Cargo.toml, crates/fj-client/Cargo.toml, and crates/fj-core/Cargo.toml, and the stage line adds all three manifests. The current version is still read from crates/fj/Cargo.toml (the published package).

The first release after this lands pulls fj-client/fj-core from 0.5.0 straight to the next bumped version, closing the existing gap.

Acceptance criteria

just create-release <bump> updates package.version in all three manifests to the same value.
All three manifests are staged in the release commit.
After a release, fj-client and fj-core versions equal forgejo-cli on main and at the tag.
The existing 0.5.0/0.6.0 gap is closed by the first release after this lands.
The recipe still reads the current version from crates/fj/Cargo.toml.

Resolves FJ-20.

#FJ-20

## Summary Fixes the `create-release` recipe so all three workspace crates move in lockstep. Previously the recipe computed and wrote the bumped version only into `crates/fj/Cargo.toml` (package `forgejo-cli`) and staged only that file, leaving `fj-client` and `fj-core` stranded at `0.5.0` while the binary advanced to `0.6.0`. ## Change In `justfile` `create-release`, the version-write step now applies the `update package.version $bare` transform to `crates/fj/Cargo.toml`, `crates/fj-client/Cargo.toml`, and `crates/fj-core/Cargo.toml`, and the stage line adds all three manifests. The current version is still read from `crates/fj/Cargo.toml` (the published package). The first release after this lands pulls `fj-client`/`fj-core` from `0.5.0` straight to the next bumped version, closing the existing gap. ## Acceptance criteria - [x] `just create-release <bump>` updates `package.version` in all three manifests to the same value. - [x] All three manifests are staged in the release commit. - [x] After a release, `fj-client` and `fj-core` versions equal `forgejo-cli` on `main` and at the tag. - [x] The existing `0.5.0`/`0.6.0` gap is closed by the first release after this lands. - [x] The recipe still reads the current version from `crates/fj/Cargo.toml`. Resolves FJ-20. #FJ-20

David added 1 commit

2026-05-28 04:11:04 +02:00

chore(release): bump library crates in lockstep with binary (FJ-20)

Check / fmt + clippy + build + tests (pull_request) Successful in 35s

Details

4d805cbc37

The create-release recipe bumped only crates/fj/Cargo.toml (package forgejo-cli) and staged just that file, leaving fj-client and fj-core stranded at 0.5.0 while the binary advanced. Extend the version-write step to update package.version in all three member manifests and stage all three, so every release moves the workspace in lockstep. The first release after this lands pulls the two libraries from 0.5.0 to the next bumped version, closing the existing gap. The current version is still read from crates/fj/Cargo.toml (the published package).

Signed-off-by: David Randall <David@NiceGuyIT.biz>

#FJ-20

David referenced this pull request from a commit

2026-05-28 04:15:10 +02:00

ci(release): sync Cargo.lock in create-release and gate normal CI on --locked

David referenced this pull request

2026-05-28 04:15:24 +02:00

ci(release): sync Cargo.lock in create-release and gate CI on --locked (FJ-21) #20

David added 2 commits

2026-05-28 10:01:35 +02:00

ci(release): sync Cargo.lock in create-release and gate normal CI on --locked 28ee30de13

Two coupled fixes so lock drift can never make it into a release commit, and so any drift in normal development fails CI on the PR rather than at release-build time.

In `justfile` `create-release`, after the lockstep manifest bump (FJ-20) and before `git commit`, run `cargo update --workspace` to rewrite only the workspace member entries in `Cargo.lock` and stage the lockfile alongside the three manifests. `cargo update --workspace` is the targeted operation: it touches only workspace members, leaves third-party pins alone, and avoids a full compile.

In `.forgejo/workflows/check.yml`, add `--locked` to both `cargo build --all-targets` (step `Build`) and `cargo test` (step `Unit tests`). The release Docker build already uses `--locked` (`oci-build/Dockerfile` lines 39, 71 and `oci-build/Dockerfile.windows` lines 39, 63); mirroring it in ordinary CI moves drift detection from release time to PR time, which is where it is cheap to fix. The `v0.6.0` release was bitten by exactly this: the release commit bumped `crates/fj/Cargo.toml` to `0.6.0` but left `Cargo.lock`'s `forgejo-cli` entry at `0.5.0`, and the lock had to be patched post-hoc in `94534e9`.

Stacked on FJ-20 (PR #19): this branch's base is `chore/create-release-bump-libs-lockstep-fj-20`, so the `git add` line in the recipe already lists all three manifests. Merge FJ-20 first; the FJ-21 diff then reduces to the `cargo update --workspace` line, the `Cargo.lock` prepend on the `git add` line, and the two `--locked` flags in `check.yml`.

Signed-off-by: David Randall <David@NiceGuyIT.biz>

#FJ-21