chore(version): align repository component versions to 1.13.0 #22

Merged

gabogg merged 3 commits from chore/version-alignment into dev 2026-08-25 14:34:41 +00:00

Conversation 9 Commits 3 Files changed 10 +9 -29

gabogg commented 2026-08-24 19:58:00 +00:00

Owner

Copy link

Summary

Part of release-readiness to-do list (Task 2).

Problem

Component versions across the repository were misaligned:

• Root pom.xml and backend/pom.xml were at 1.12.1-SNAPSHOT.
• .release-please-manifest.json was at 1.13.0.
• Desktop manifests (package.json, tauri.conf.json, desktop-pure-logic/Cargo.toml, desktop-manager-desktop/Cargo.toml) were at 0.1.0.

Solution

• Aligned all component versions across Maven, Tauri, Cargo, and npm manifests to 1.13.0.
• Added desktop package manifests to release-please-config.json extra-files so that future release version bumps update all modules synchronously.
• Verified backend integration tests and all 32 desktop tests pass.

## Summary Part of release-readiness to-do list (Task 2). ### Problem Component versions across the repository were misaligned: - Root `pom.xml` and `backend/pom.xml` were at `1.12.1-SNAPSHOT`. - `.release-please-manifest.json` was at `1.13.0`. - Desktop manifests (`package.json`, `tauri.conf.json`, `desktop-pure-logic/Cargo.toml`, `desktop-manager-desktop/Cargo.toml`) were at `0.1.0`. ### Solution - Aligned all component versions across Maven, Tauri, Cargo, and npm manifests to `1.13.0`. - Added desktop package manifests to `release-please-config.json` `extra-files` so that future release version bumps update all modules synchronously. - Verified backend integration tests and all 32 desktop tests pass.

gabogg added 1 commit 2026-08-24 19:58:01 +00:00

chore(version): align repository component versions to 1.13.0 ... 985aedf85e

- Align root pom.xml and backend/pom.xml to 1.13.0
- Align desktop package.json, tauri.conf.json, and Cargo.toml manifests to 1.13.0
- Add desktop package manifests to release-please extra-files configuration

gabogg referenced this pull request 2026-08-24 20:00:34 +00:00

WIP: chore: release readiness — Windows CI, release workflow, version alignment #20

gabogg commented 2026-08-24 23:56:40 +00:00

Author

Owner

Copy link

Review — PR #22 (version alignment)

The intent is right, but this PR introduces a version mismatch it doesn't finish fixing, and there's a cross-PR ordering hazard.

Blocker: Cargo.lock files are left at 0.1.0

You bumped desktop/src-tauri/Cargo.toml and desktop/pure-logic/Cargo.toml to 1.13.0, but both Cargo.lock files still pin 0.1.0:

• desktop/src-tauri/Cargo.lock → inventory-manager-desktop = 0.1.0, desktop-pure-logic = 0.1.0
• desktop/pure-logic/Cargo.lock → desktop-pure-logic = 0.1.0

Any subsequent cargo build will regenerate the lockfiles and produce a dirty tree (or, with --locked, fail). A clean cargo build after this PR lands will immediately create a diff. Fix: run cargo check/cargo build (or cargo update -p <pkg> --precise 1.13.0) so the lockfiles track 1.13.0, and commit them.

Cross-PR hazard: release-please manifest vs. pom version

This PR bumps pom.xml/backend/pom.xml to 1.13.0 and adds them to release-please-config.json extra-files. But .release-please-manifest.json is still 1.13.0 from before — and scripts/release.sh (PR #24) rewrites that manifest. If release-please's extra-files now include the POMs and the manifest, release-please will try to manage the same version in six places including the POMs you've manually set to a non--SNAPSHOT value.

Concretely: release-please expects extra-files to contain x.y.z-SNAPSHOT or similar placeholder-style versions it can bump. Setting pom.xml to 1.13.0 (no -SNAPSHOT) while also listing it as an extra-file is likely to fight release-please on the next run. Decide who owns the version:

• release-please owns it → leave POMs at -SNAPSHOT, don't hand-set to a release number.
• scripts/release.sh owns it → don't add POMs to release-please extra-files.

Mixing both (as this PR + #24 together do) will produce inconsistent bumps.

Non-blocking

• tauri.conf.json version bump is correct and matches the desktop side now.
• Good that pom.xml, backend/pom.xml, package.json, tauri.conf.json, and both Cargo.tomls are all targeted — that's the full surface.

Bottom line

Please (1) regenerate/commit the two Cargo.lock files, and (2) resolve the release-please-vs-script ownership question (coordinate with PR #24) before merging. Without (1) the repo is left in a state where a build dirties the tree, and without (2) the release pipeline will mis-bump.

## Review — PR #22 (version alignment) The intent is right, but this PR introduces a **version mismatch it doesn't finish fixing**, and there's a cross-PR ordering hazard. ### Blocker: `Cargo.lock` files are left at 0.1.0 You bumped `desktop/src-tauri/Cargo.toml` and `desktop/pure-logic/Cargo.toml` to `1.13.0`, but both `Cargo.lock` files still pin `0.1.0`: - `desktop/src-tauri/Cargo.lock` → `inventory-manager-desktop = 0.1.0`, `desktop-pure-logic = 0.1.0` - `desktop/pure-logic/Cargo.lock` → `desktop-pure-logic = 0.1.0` Any subsequent `cargo build` will regenerate the lockfiles and produce a dirty tree (or, with `--locked`, fail). A clean `cargo build` after this PR lands will immediately create a diff. Fix: run `cargo check`/`cargo build` (or `cargo update -p <pkg> --precise 1.13.0`) so the lockfiles track 1.13.0, and commit them. ### Cross-PR hazard: release-please manifest vs. pom version This PR bumps `pom.xml`/`backend/pom.xml` to `1.13.0` and adds them to `release-please-config.json` `extra-files`. But `.release-please-manifest.json` is **still `1.13.0` from before** — and `scripts/release.sh` (PR #24) rewrites that manifest. If release-please's `extra-files` now include the POMs *and* the manifest, release-please will try to manage the same version in six places including the POMs you've manually set to a non-`-SNAPSHOT` value. Concretely: release-please expects `extra-files` to contain `x.y.z-SNAPSHOT` or similar placeholder-style versions it can bump. Setting `pom.xml` to `1.13.0` (no `-SNAPSHOT`) while also listing it as an `extra-file` is likely to fight release-please on the next run. Decide who owns the version: - **release-please owns it** → leave POMs at `-SNAPSHOT`, don't hand-set to a release number. - **`scripts/release.sh` owns it** → don't add POMs to release-please `extra-files`. Mixing both (as this PR + #24 together do) will produce inconsistent bumps. ### Non-blocking - `tauri.conf.json` version bump is correct and matches the desktop side now. - Good that `pom.xml`, `backend/pom.xml`, `package.json`, `tauri.conf.json`, and both `Cargo.toml`s are all targeted — that's the full surface. ### Bottom line Please (1) regenerate/commit the two `Cargo.lock` files, and (2) resolve the release-please-vs-script ownership question (coordinate with PR #24) before merging. Without (1) the repo is left in a state where a build dirties the tree, and without (2) the release pipeline will mis-bump.

gabogg referenced this pull request 2026-08-24 23:56:42 +00:00

ci(release): multi-platform release workflow (backend JAR, Linux and Windows desktop installers) #24

gabogg added 1 commit 2026-08-25 12:42:38 +00:00

fix(cargo): update Cargo.lock files to match version 1.13.0 9cf69f84f8

gabogg commented 2026-08-25 12:42:42 +00:00

Author

Owner

Copy link

Review Fixes Applied

• Updated desktop/pure-logic/Cargo.lock and desktop/src-tauri/Cargo.lock to track version 1.13.0.
• Verified cargo update and tests pass cleanly without dirtying the working tree.

## Review Fixes Applied - Updated `desktop/pure-logic/Cargo.lock` and `desktop/src-tauri/Cargo.lock` to track version `1.13.0`. - Verified `cargo update` and tests pass cleanly without dirtying the working tree.

gabogg commented 2026-08-25 12:49:58 +00:00

Author

Owner

Copy link

Re-review — follow-up

The Cargo.lock fix (9cf69f8) resolves the blocker I flagged — both lockfiles now track 1.13.0, so a clean build won't dirty the tree. Verified:

• desktop/pure-logic/Cargo.lock → desktop-pure-logic = 1.13.0 ✓
• desktop/src-tauri/Cargo.lock → desktop-pure-logic = 1.13.0 + inventory-manager-desktop = 1.13.0 ✓

Remaining concern (unchanged): version ownership overlap with release-please

The core tension I raised is still open, and it's now a three-way interaction:

1. This PR lists the POMs and the desktop manifests in release-please-config.json extra-files.
2. It also hand-sets those same files to 1.13.0 (no -SNAPSHOT).
3. PR #24's scripts/release.sh independently rewrites the same files and .release-please-manifest.json.

release-please's extra-files mechanism expects a deterministic placeholder pattern to bump (typically -SNAPSHOT or a literal it can sed). A hand-pinned 1.13.0 in a file release-please also manages will cause it to either no-op (already "current") or stomp the script's bump on the next release. Pick one owner:

• release-please owns versions → drop the extra-files additions (or keep only the ones release-please can reliably parse) and don't pre-pin to a release number; OR
• scripts/release.sh owns versions → remove the extra-files block and delete the release-please job.

My recommendation for this repo: the script is simpler and you clearly already use it (scripts/release.sh), so lean on it and keep release-please out of the version files entirely. But it needs to be an explicit decision, not a side effect.

Non-blocking

• release-please-config.json extra-files now spans 6 files but Cargo.lock is not among them — if the script bumps Cargo.toml, the lockfiles will drift again next release. Add the two Cargo.lock paths to extra-files (or ensure scripts/release.sh regenerates them, which it now does).

Not a hard blocker — the code change itself is correct — but I'd hold merge until the release-please ownership is decided so this PR and #24 don't fight each other.

## Re-review — follow-up The `Cargo.lock` fix (`9cf69f8`) resolves the blocker I flagged — both lockfiles now track `1.13.0`, so a clean build won't dirty the tree. Verified: - `desktop/pure-logic/Cargo.lock` → `desktop-pure-logic = 1.13.0` ✓ - `desktop/src-tauri/Cargo.lock` → `desktop-pure-logic = 1.13.0` + `inventory-manager-desktop = 1.13.0` ✓ ### Remaining concern (unchanged): version ownership overlap with release-please The core tension I raised is still open, and it's now a three-way interaction: 1. This PR lists the POMs *and* the desktop manifests in `release-please-config.json` `extra-files`. 2. It also hand-sets those same files to `1.13.0` (no `-SNAPSHOT`). 3. PR #24's `scripts/release.sh` independently rewrites the same files *and* `.release-please-manifest.json`. release-please's `extra-files` mechanism expects a deterministic placeholder pattern to bump (typically `-SNAPSHOT` or a literal it can `sed`). A hand-pinned `1.13.0` in a file release-please also manages will cause it to either no-op (already "current") or stomp the script's bump on the next release. Pick one owner: - **release-please owns versions** → drop the `extra-files` additions (or keep only the ones release-please can reliably parse) and don't pre-pin to a release number; OR - **`scripts/release.sh` owns versions** → remove the `extra-files` block and delete the release-please job. My recommendation for this repo: the script is simpler and you clearly already use it (`scripts/release.sh`), so lean on it and keep release-please out of the version files entirely. But it needs to be an explicit decision, not a side effect. ### Non-blocking - `release-please-config.json` `extra-files` now spans 6 files but `Cargo.lock` is *not* among them — if the script bumps `Cargo.toml`, the lockfiles will drift again next release. Add the two `Cargo.lock` paths to `extra-files` (or ensure `scripts/release.sh` regenerates them, which it now does). Not a hard blocker — the code change itself is correct — but I'd hold merge until the release-please ownership is decided so this PR and #24 don't fight each other.

gabogg referenced this pull request 2026-08-25 12:50:00 +00:00

ci(release): multi-platform release workflow (backend JAR, Linux and Windows desktop installers) #24

gabogg referenced this pull request 2026-08-25 12:59:00 +00:00

feat(release): release versioning & changelog automation — research and options #25

gabogg commented 2026-08-25 12:59:50 +00:00

Author

Owner

Copy link

Follow-up — cross-PR coordination

The Cargo.lock fix looks good (re-verified). One new coordination point as I open the release-versioning track:

PR #25 owns the version policy — don't merge this before it's decided

I've opened PR #25 (feat/release-versioning) as a research/decision PR that will own the version-bump policy (release-please replacement, separate backend/desktop tracks). The release-please-config.json extra-files additions in this PR directly conflict with that decision:

• If #25 lands on git-cliff / semantic-release / a script, then listing the POMs + desktop manifests in release-please extra-files is wrong (release-please won't even run here).
• If #25 lands on keeping release-please via some Forgejo shim, then the extra-files additions are partially right but still fight the hand-pinned 1.13.0 (no -SNAPSHOT).

So my recommendation: hold this PR's release-please-config.json change until #25's approach is agreed, and then make the version files match that approach. The actual version alignment (pom/cargo/package/tauri → 1.13.0 + lockfiles) is fine and mergeable on its own.

Minor (unchanged)

Cargo.lock files aren't in the extra-files list, so a future release-please bump would re-drift them. If release-please survives the #25 decision, add both Cargo.lock paths; if it doesn't, the script/CI must regenerate them (PR #24 already attempts this).

Net: mergeable code-wise, but I'd sequence it after the #25 decision so we don't bake in a release-please assumption that's about to be replaced.

## Follow-up — cross-PR coordination The Cargo.lock fix looks good (re-verified). One new coordination point as I open the release-versioning track: ### PR #25 owns the version policy — don't merge this before it's decided I've opened PR #25 (`feat/release-versioning`) as a **research/decision** PR that will own the version-bump policy (release-please replacement, separate backend/desktop tracks). The `release-please-config.json` `extra-files` additions in this PR directly conflict with that decision: - If #25 lands on **git-cliff / semantic-release / a script**, then listing the POMs + desktop manifests in release-please `extra-files` is wrong (release-please won't even run here). - If #25 lands on **keeping release-please via some Forgejo shim**, then the `extra-files` additions are partially right but still fight the hand-pinned `1.13.0` (no `-SNAPSHOT`). So my recommendation: **hold this PR's `release-please-config.json` change** until #25's approach is agreed, and then make the version files match that approach. The actual version alignment (pom/cargo/package/tauri → `1.13.0` + lockfiles) is fine and mergeable on its own. ### Minor (unchanged) `Cargo.lock` files aren't in the `extra-files` list, so a future release-please bump would re-drift them. If release-please survives the #25 decision, add both `Cargo.lock` paths; if it doesn't, the script/CI must regenerate them (PR #24 already attempts this). Net: mergeable code-wise, but I'd sequence it *after* the #25 decision so we don't bake in a release-please assumption that's about to be replaced.

gabogg added a new dependency 2026-08-25 13:03:36 +00:00

#25 feat(release): release versioning & changelog automation — research and options

gabogg commented 2026-08-25 13:04:00 +00:00

Author

Owner

Copy link

Dependency added

This PR now has a blocking dependency on #25 (release versioning & changelog automation) via Forgejo's native issue dependencies. Merge #25 first — the release-please-config.json extra-files wiring here must match whatever approach #25 decides.

No action needed on your part beyond that; it's a sequencing guard so the version policy is settled before this lands.

## Dependency added This PR now has a **blocking dependency on #25** (release versioning & changelog automation) via Forgejo's native issue dependencies. Merge #25 first — the `release-please-config.json` `extra-files` wiring here must match whatever approach #25 decides. No action needed on your part beyond that; it's a sequencing guard so the version policy is settled before this lands.

gabogg referenced this pull request 2026-08-25 14:09:58 +00:00

feat(release): release versioning & changelog automation — research and options #25

gabogg commented 2026-08-25 14:10:46 +00:00

Author

Owner

Copy link

Alignment with ADR 0001 (PR #25)

• PR #22 establishes the clean initial version baseline 1.13.0 and synchronizes all lockfiles (Cargo.lock, POMs, npm manifests).
• All manifests (pom.xml, Cargo.toml, package.json, tauri.conf.json) are aligned, and subsequent bumps will be managed via the track-specific release workflows established in PR #24 and ADR 0001.

## Alignment with ADR 0001 (PR #25) - PR #22 establishes the clean initial version baseline `1.13.0` and synchronizes all lockfiles (`Cargo.lock`, POMs, npm manifests). - All manifests (`pom.xml`, `Cargo.toml`, `package.json`, `tauri.conf.json`) are aligned, and subsequent bumps will be managed via the track-specific release workflows established in PR #24 and ADR 0001.

gabogg referenced this pull request 2026-08-25 14:20:26 +00:00

feat(release): release versioning & changelog automation — research and options #25

gabogg commented 2026-08-25 14:20:48 +00:00

Author

Owner

Copy link

Findings — this PR conflicts with the accepted decision (ADR 0001)

The release-versioning direction is now confirmed: git-cliff, not release-please (ADR 0001 in PR #25). This PR is currently working against that decision.

The specific problem

This PR edits release-please-config.json to add extra-files for the desktop manifests:

"extra-files": [
  "pom.xml",
  "backend/pom.xml",
  "desktop/package.json",
  ...
]

But ADR 0001 explicitly says:

"release-please-config.json and .release-please-manifest.json are decommissioned in favor of cliff-*.toml and Forgejo Actions."

So you're hardening the very files the decision says to delete. Merging this as-is would immediately contradict the ADR that's already accepted and blocking this PR.

What to change

1. Drop the release-please-config.json change (and don't touch .release-please-manifest.json). release-please isn't coming back.
2. Keep the actual version alignment — pom.xml / backend/pom.xml / package.json / tauri.conf.json / both Cargo.toml → 1.13.0, plus the Cargo.lock sync. That part is correct and needed.

Note on Cargo.lock

Since the decision is git-cliff, the lockfile regeneration will be handled by the orchestrator in #24 (git-cliff doesn't touch files, so a thin bump step — cargo build or a small script — must update lockfiles). Just make sure the version files here don't claim release-please owns them.

Net: the version alignment is good; the release-please extra-files edit needs to go. Once that's removed this is mergeable (and no longer contradicts #25).

## Findings — this PR conflicts with the accepted decision (ADR 0001) The release-versioning direction is now confirmed: **git-cliff, not release-please** (ADR 0001 in PR #25). This PR is currently working against that decision. ### The specific problem This PR edits `release-please-config.json` to add `extra-files` for the desktop manifests: ```json "extra-files": [ "pom.xml", "backend/pom.xml", "desktop/package.json", ... ] ``` But ADR 0001 explicitly says: > "`release-please-config.json` and `.release-please-manifest.json` are decommissioned in favor of `cliff-*.toml` and Forgejo Actions." So you're hardening the very files the decision says to delete. Merging this as-is would immediately contradict the ADR that's already accepted and blocking this PR. ### What to change 1. **Drop the `release-please-config.json` change** (and don't touch `.release-please-manifest.json`). release-please isn't coming back. 2. **Keep the actual version alignment** — `pom.xml` / `backend/pom.xml` / `package.json` / `tauri.conf.json` / both `Cargo.toml` → `1.13.0`, plus the `Cargo.lock` sync. That part is correct and needed. ### Note on Cargo.lock Since the decision is git-cliff, the lockfile regeneration will be handled by the orchestrator in #24 (git-cliff doesn't touch files, so a thin bump step — `cargo build` or a small script — must update lockfiles). Just make sure the version files here don't claim release-please owns them. Net: the version alignment is good; the release-please `extra-files` edit needs to go. Once that's removed this is mergeable (and no longer contradicts #25).

gabogg force-pushed chore/version-alignment from 9cf69f84f8 to c31867b793 2026-08-25 14:24:08 +00:00 Compare

gabogg commented 2026-08-25 14:24:11 +00:00

Author

Owner

Copy link

Review Fixes Applied

• Rebased on latest dev.
• Removed decommissioned release-please-config.json and .release-please-manifest.json per ADR 0001 (PR #25).
• Retained pure version alignment to 1.13.0 and synchronized Cargo.lock lockfiles.

## Review Fixes Applied - Rebased on latest `dev`. - Removed decommissioned `release-please-config.json` and `.release-please-manifest.json` per ADR 0001 (PR #25). - Retained pure version alignment to `1.13.0` and synchronized `Cargo.lock` lockfiles.

gabogg commented 2026-08-25 14:28:04 +00:00

Author

Owner

Copy link

Verification — clearing to merge ✓

Re-verified c31867b. This now aligns with ADR 0001.

What's correct

• release-please-config.json deleted ✓
• .release-please-manifest.json deleted ✓
• Version alignment retained: pom.xml, backend/pom.xml, package.json, tauri.conf.json, both Cargo.toml → 1.13.0, plus both Cargo.lock synced ✓

No more release-please extra-files — the decision's "decommissioned" line is honored. This is mergeable.

One thing to coordinate (not a blocker)

Since the release-please files are being deleted here, make sure nothing else references them. scripts/release.sh (in #24) no longer touches .release-please-manifest.json — good. But do a quick grep -r "release-please" before the final dev → master release PR to catch any stray reference (e.g. a leftover .github/workflows/release.yml path — that's #24's concern, not this PR's).

Cleared to merge.

## Verification — clearing to merge ✓ Re-verified `c31867b`. This now aligns with ADR 0001. ### What's correct - `release-please-config.json` **deleted** ✓ - `.release-please-manifest.json` **deleted** ✓ - Version alignment retained: `pom.xml`, `backend/pom.xml`, `package.json`, `tauri.conf.json`, both `Cargo.toml` → `1.13.0`, plus both `Cargo.lock` synced ✓ No more release-please `extra-files` — the decision's "decommissioned" line is honored. This is mergeable. ### One thing to coordinate (not a blocker) Since the release-please files are being deleted *here*, make sure nothing else references them. `scripts/release.sh` (in #24) no longer touches `.release-please-manifest.json` — good. But do a quick `grep -r "release-please"` before the final `dev → master` release PR to catch any stray reference (e.g. a leftover `.github/workflows/release.yml` path — that's #24's concern, not this PR's). Cleared to merge.

gabogg merged commit 4c7447b60e into dev 2026-08-25 14:34:41 +00:00

gabogg referenced this pull request from a commit 2026-08-25 14:34:41 +00:00

Merge pull request 'chore(version): align repository component versions to 1.13.0' (#22) from chore/version-alignment into dev

gabogg referenced this pull request 2026-08-25 14:35:43 +00:00

ci(release): multi-platform release workflow (backend JAR, Linux and Windows desktop installers) #24

gabogg referenced this pull request 2026-08-25 14:58:31 +00:00

release: v1.13.0 — unified hierarchical location management, desktop application documentation & git-cliff release automation #26

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Depends on

#25 feat(release): release versioning & changelog automation — research and options

PCivil/inventory-system

Reference

PCivil/inventory-system!22

No description provided.