Skip to content

chore(release): promote develop to main (2.0 stable-line sync)#401

Merged
DemchaAV merged 7 commits into
mainfrom
develop
Jul 13, 2026
Merged

chore(release): promote develop to main (2.0 stable-line sync)#401
DemchaAV merged 7 commits into
mainfrom
develop

Conversation

@DemchaAV

Copy link
Copy Markdown
Owner

Why

Bring main in sync with develop so the stable branch reflects the current 2.0 line. This is a branch synchronization only — no tag, no GitHub Release, no Maven Central publication.

What

Promotes the 7 commits currently on develop but not main:

main's project version moves 2.0.02.0.1-SNAPSHOT (inherited from #394's post-release bump, already on develop). Public install snippets stay on 2.0.0; v2.0.0 remains the latest published release.

Tests

develop is green at da7d1848 (CI Gate + Architecture and Documentation Guards). CI re-runs on this PR.

dependabot Bot and others added 7 commits July 13, 2026 09:53
…h 8 updates (#391)

Bumps the maven-minor-patch group with 8 updates in the / directory:

| Package | From | To |
| --- | --- | --- |
| [org.junit:junit-bom](https://github.com/junit-team/junit-framework) | `6.1.1` | `6.1.2` |
| [ch.qos.logback:logback-classic](https://github.com/qos-ch/logback) | `1.5.37` | `1.5.38` |
| [org.junit.jupiter:junit-jupiter](https://github.com/junit-team/junit-framework) | `6.1.1` | `6.1.2` |
| [net.jqwik:jqwik](https://github.com/jqwik-team/jqwik) | `1.9.3` | `1.10.1` |
| [org.jacoco:jacoco-maven-plugin](https://github.com/jacoco/jacoco) | `0.8.12` | `0.8.15` |
| org.apache.pdfbox:pdfbox | `3.0.7` | `3.0.8` |
| [com.fasterxml.jackson.core:jackson-databind](https://github.com/FasterXML/jackson) | `2.21.4` | `2.22.1` |
| [com.itextpdf:itext-core](https://github.com/itext/itext7) | `9.6.0` | `9.7.0` |

Bumps the maven-minor-patch group with 3 updates in the /benchmarks directory: [org.junit:junit-bom](https://github.com/junit-team/junit-framework), [ch.qos.logback:logback-classic](https://github.com/qos-ch/logback) and [com.itextpdf:itext-core](https://github.com/itext/itext7).
Bumps the maven-minor-patch group with 2 updates in the /examples directory: [org.junit:junit-bom](https://github.com/junit-team/junit-framework) and [ch.qos.logback:logback-classic](https://github.com/qos-ch/logback).


Updates `org.junit:junit-bom` from 6.1.1 to 6.1.2
- [Release notes](https://github.com/junit-team/junit-framework/releases)
- [Commits](junit-team/junit-framework@r6.1.1...r6.1.2)

Updates `ch.qos.logback:logback-classic` from 1.5.37 to 1.5.38
- [Release notes](https://github.com/qos-ch/logback/releases)
- [Commits](qos-ch/logback@v_1.5.37...v_1.5.38)

Updates `org.junit.jupiter:junit-jupiter` from 6.1.1 to 6.1.2
- [Release notes](https://github.com/junit-team/junit-framework/releases)
- [Commits](junit-team/junit-framework@r6.1.1...r6.1.2)

Updates `net.jqwik:jqwik` from 1.9.3 to 1.10.1
- [Release notes](https://github.com/jqwik-team/jqwik/releases)
- [Commits](jqwik-team/jqwik@1.9.3...1.10.1)

Updates `org.jacoco:jacoco-maven-plugin` from 0.8.12 to 0.8.15
- [Release notes](https://github.com/jacoco/jacoco/releases)
- [Commits](jacoco/jacoco@v0.8.12...v0.8.15)

Updates `org.apache.pdfbox:pdfbox` from 3.0.7 to 3.0.8

Updates `com.fasterxml.jackson.core:jackson-databind` from 2.21.4 to 2.22.1
- [Commits](https://github.com/FasterXML/jackson/commits)

Updates `com.itextpdf:itext-core` from 9.6.0 to 9.7.0
- [Release notes](https://github.com/itext/itext7/releases)
- [Commits](itext/itext-java@9.6.0...9.7.0)

Updates `org.junit:junit-bom` from 6.1.1 to 6.1.2
- [Release notes](https://github.com/junit-team/junit-framework/releases)
- [Commits](junit-team/junit-framework@r6.1.1...r6.1.2)

Updates `ch.qos.logback:logback-classic` from 1.5.37 to 1.5.38
- [Release notes](https://github.com/qos-ch/logback/releases)
- [Commits](qos-ch/logback@v_1.5.37...v_1.5.38)

Updates `com.itextpdf:itext-core` from 9.6.0 to 9.7.0
- [Release notes](https://github.com/itext/itext7/releases)
- [Commits](itext/itext-java@9.6.0...9.7.0)

Updates `org.junit.jupiter:junit-jupiter` from 6.1.1 to 6.1.2
- [Release notes](https://github.com/junit-team/junit-framework/releases)
- [Commits](junit-team/junit-framework@r6.1.1...r6.1.2)

Updates `org.junit:junit-bom` from 6.1.1 to 6.1.2
- [Release notes](https://github.com/junit-team/junit-framework/releases)
- [Commits](junit-team/junit-framework@r6.1.1...r6.1.2)

Updates `ch.qos.logback:logback-classic` from 1.5.37 to 1.5.38
- [Release notes](https://github.com/qos-ch/logback/releases)
- [Commits](qos-ch/logback@v_1.5.37...v_1.5.38)

Updates `org.junit.jupiter:junit-jupiter` from 6.1.1 to 6.1.2
- [Release notes](https://github.com/junit-team/junit-framework/releases)
- [Commits](junit-team/junit-framework@r6.1.1...r6.1.2)

Updates `org.junit:junit-bom` from 6.1.1 to 6.1.2
- [Release notes](https://github.com/junit-team/junit-framework/releases)
- [Commits](junit-team/junit-framework@r6.1.1...r6.1.2)

Updates `ch.qos.logback:logback-classic` from 1.5.37 to 1.5.38
- [Release notes](https://github.com/qos-ch/logback/releases)
- [Commits](qos-ch/logback@v_1.5.37...v_1.5.38)

Updates `com.itextpdf:itext-core` from 9.6.0 to 9.7.0
- [Release notes](https://github.com/itext/itext7/releases)
- [Commits](itext/itext-java@9.6.0...9.7.0)

Updates `org.junit:junit-bom` from 6.1.1 to 6.1.2
- [Release notes](https://github.com/junit-team/junit-framework/releases)
- [Commits](junit-team/junit-framework@r6.1.1...r6.1.2)

Updates `ch.qos.logback:logback-classic` from 1.5.37 to 1.5.38
- [Release notes](https://github.com/qos-ch/logback/releases)
- [Commits](qos-ch/logback@v_1.5.37...v_1.5.38)

Updates `com.itextpdf:itext-core` from 9.6.0 to 9.7.0
- [Release notes](https://github.com/itext/itext7/releases)
- [Commits](itext/itext-java@9.6.0...9.7.0)

Updates `org.junit:junit-bom` from 6.1.1 to 6.1.2
- [Release notes](https://github.com/junit-team/junit-framework/releases)
- [Commits](junit-team/junit-framework@r6.1.1...r6.1.2)

Updates `ch.qos.logback:logback-classic` from 1.5.37 to 1.5.38
- [Release notes](https://github.com/qos-ch/logback/releases)
- [Commits](qos-ch/logback@v_1.5.37...v_1.5.38)

Updates `org.junit:junit-bom` from 6.1.1 to 6.1.2
- [Release notes](https://github.com/junit-team/junit-framework/releases)
- [Commits](junit-team/junit-framework@r6.1.1...r6.1.2)

Updates `ch.qos.logback:logback-classic` from 1.5.37 to 1.5.38
- [Release notes](https://github.com/qos-ch/logback/releases)
- [Commits](qos-ch/logback@v_1.5.37...v_1.5.38)

Updates `org.junit:junit-bom` from 6.1.1 to 6.1.2
- [Release notes](https://github.com/junit-team/junit-framework/releases)
- [Commits](junit-team/junit-framework@r6.1.1...r6.1.2)

Updates `ch.qos.logback:logback-classic` from 1.5.37 to 1.5.38
- [Release notes](https://github.com/qos-ch/logback/releases)
- [Commits](qos-ch/logback@v_1.5.37...v_1.5.38)

Updates `org.junit:junit-bom` from 6.1.1 to 6.1.2
- [Release notes](https://github.com/junit-team/junit-framework/releases)
- [Commits](junit-team/junit-framework@r6.1.1...r6.1.2)

Updates `ch.qos.logback:logback-classic` from 1.5.37 to 1.5.38
- [Release notes](https://github.com/qos-ch/logback/releases)
- [Commits](qos-ch/logback@v_1.5.37...v_1.5.38)

---
updated-dependencies:
- dependency-name: org.junit:junit-bom
  dependency-version: 6.1.2
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: maven-minor-patch
- dependency-name: ch.qos.logback:logback-classic
  dependency-version: 1.5.38
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: maven-minor-patch
- dependency-name: org.junit.jupiter:junit-jupiter
  dependency-version: 6.1.2
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: maven-minor-patch
- dependency-name: net.jqwik:jqwik
  dependency-version: 1.10.1
  dependency-type: direct:development
  update-type: version-update:semver-minor
  dependency-group: maven-minor-patch
- dependency-name: org.jacoco:jacoco-maven-plugin
  dependency-version: 0.8.15
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: maven-minor-patch
- dependency-name: org.apache.pdfbox:pdfbox
  dependency-version: 3.0.8
  dependency-type: direct:development
  update-type: version-update:semver-patch
  dependency-group: maven-minor-patch
- dependency-name: com.fasterxml.jackson.core:jackson-databind
  dependency-version: 2.22.1
  dependency-type: direct:development
  update-type: version-update:semver-minor
  dependency-group: maven-minor-patch
- dependency-name: com.itextpdf:itext-core
  dependency-version: 9.7.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: maven-minor-patch
- dependency-name: org.junit:junit-bom
  dependency-version: 6.1.2
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: maven-minor-patch
- dependency-name: ch.qos.logback:logback-classic
  dependency-version: 1.5.38
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: maven-minor-patch
- dependency-name: com.itextpdf:itext-core
  dependency-version: 9.7.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: maven-minor-patch
- dependency-name: org.junit.jupiter:junit-jupiter
  dependency-version: 6.1.2
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: maven-minor-patch
- dependency-name: org.junit:junit-bom
  dependency-version: 6.1.2
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: maven-minor-patch
- dependency-name: ch.qos.logback:logback-classic
  dependency-version: 1.5.38
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: maven-minor-patch
- dependency-name: org.junit.jupiter:junit-jupiter
  dependency-version: 6.1.2
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: maven-minor-patch
- dependency-name: org.junit:junit-bom
  dependency-version: 6.1.2
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: maven-minor-patch
- dependency-name: ch.qos.logback:logback-classic
  dependency-version: 1.5.38
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: maven-minor-patch
- dependency-name: com.itextpdf:itext-core
  dependency-version: 9.7.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: maven-minor-patch
- dependency-name: org.junit:junit-bom
  dependency-version: 6.1.2
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: maven-minor-patch
- dependency-name: ch.qos.logback:logback-classic
  dependency-version: 1.5.38
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: maven-minor-patch
- dependency-name: com.itextpdf:itext-core
  dependency-version: 9.7.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: maven-minor-patch
- dependency-name: org.junit:junit-bom
  dependency-version: 6.1.2
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: maven-minor-patch
- dependency-name: ch.qos.logback:logback-classic
  dependency-version: 1.5.38
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: maven-minor-patch
- dependency-name: org.junit:junit-bom
  dependency-version: 6.1.2
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: maven-minor-patch
- dependency-name: ch.qos.logback:logback-classic
  dependency-version: 1.5.38
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: maven-minor-patch
- dependency-name: org.junit:junit-bom
  dependency-version: 6.1.2
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: maven-minor-patch
- dependency-name: ch.qos.logback:logback-classic
  dependency-version: 1.5.38
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: maven-minor-patch
- dependency-name: org.junit:junit-bom
  dependency-version: 6.1.2
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: maven-minor-patch
- dependency-name: ch.qos.logback:logback-classic
  dependency-version: 1.5.38
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: maven-minor-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Artem Demchyshyn <132658418+DemchaAV@users.noreply.github.com>
…ne (#394)

* build(japicmp): enforce binary compatibility against the 2.0.0 baseline

The japicmp gate ran report-only through the 2.0 major transition and
compared against a JitPack-hosted v1.7.0. With 2.0.0 published to Maven
Central, point the baseline at graph-compose-core:2.0.0 (resolved from
Central, no extra repository) and fail the build on any binary-incompatible
change to the public surface, so a regression can no longer ship in a 2.x
update. Source-incompatible changes stay report-only. The baseline is the
major's floor and holds for the whole 2.x line, advancing only at the next
major.

The gate short-circuits when the working version equals the baseline, so it
only bites once development moves off the release version: bump every module
to 2.0.1-SNAPSHOT. The install snippets stay pinned to the published 2.0.0,
so VersionConsistencyGuard now also accepts the latest published release
(the topmost dated CHANGELOG entry) alongside the pom and Planned versions.
Drop the two stale 1.x removal excludes (TextMeasurementSystem, ConfigLoader)
— the 2.0.0 baseline predates them.

Tests: VersionConsistencyGuardTest 12/12 (poms 2.0.1-SNAPSHOT, snippets
2.0.0); reactor-wide `mvn validate` green; `-P japicmp verify` on core is
BUILD SUCCESS against 2.0.0, and a controlled public->package-private change
fails with METHOD_LESS_ACCESSIBLE.

* build(japicmp): exclude the full Internal surface, add a publish preflight

Align the binary-compatibility gate with docs/api-stability.md. The Internal tier
— com.demcha.compose.engine.** and com.demcha.compose.document.layout.**, plus any
element marked @internal — carries no compatibility promise, so exclude all of it;
the gate previously excluded only document.layout.payloads. Only the Stable public
surface is now enforced.

Run the gate in the publish workflow before any deploy, so a binary-incompatible
change to the public surface aborts the release even if the tag reached the publish
job by bypassing branch protection (the CI japicmp job only gates pull requests).

Tighten VersionConsistencyGuardTest: during a -SNAPSHOT development cycle the
install snippets must advertise the latest published release (the version
resolvable on Maven Central), not the in-development SNAPSHOT or a Planned version.
The release commit bumps the pom off SNAPSHOT and rewrites the snippets to the
release version, at which point they must equal it.

Verified on a 2.0.1-SNAPSHOT working tree: the gate fails a Stable break
(DocumentColor.rgba -> package-private, METHOD_LESS_ACCESSIBLE) and passes an
Internal break (LayoutCompiler.compile -> package-private, excluded); the guard
rejects a snippet pinned to an unpublished 2.0.1.

* test(japicmp): add a controlled Stable/Internal exclude verification

A git-revert-safe script that proves the gate enforces the Stable surface and
excludes the Internal surface: it reduces a Stable public method to
package-private and asserts the gate FAILS (METHOD_LESS_ACCESSIBLE), then does
the same to an Internal method and asserts the gate PASSES. A trap always reverts
the source. Run it after changing the japicmp <excludes> or moving a type between
tiers.
Two statements in the multi-module packaging ADR described a superseded
draft rather than what shipped:

- Engine sources are in the `core/` module (coordinate `graph-compose-core`),
  not "at the repository root" — the root is the `graph-compose-build`
  aggregator pom that binds the reactor.
- The dormant Entity-Component-System internals (EntityManager / SystemECS
  runtime, the Entity model, the ECS render pipeline) were removed in 2.0.0,
  not moved into a module with removal deferred. They were unreachable from
  the live render path, so layout, PDF output, and guideLines(...) are
  unchanged.

Documentation guards (CanonicalSurface, DocumentationCoverage, PackageMap,
VersionConsistency) stay green.
…ules (#396)

* test(release-smoke): add external consumer smoke projects for the 2.0 modules

Prove the modular 2.0 release works for a real consumer resolving from Maven
Central, outside the reactor and with no local install behind it. Six standalone
Maven projects (no <parent>, so the reactor never builds them), each verifying
one published-artifact scenario:

- graph-compose renders a PDF out of the box (the drop-in wrapper);
- graph-compose-core alone throws MissingBackendException naming
  graph-compose-render-pdf, and its dependency tree pulls no PDFBox / POI / ZXing
  / templates / fonts / emoji (maven-enforcer bannedDependencies);
- graph-compose-core + graph-compose-render-pdf render via the ServiceLoader SPI;
- graph-compose-templates composes a built-in template through the PDF stack;
- graph-compose-testing round-trips a layout snapshot (LayoutSnapshotAssertions);
- graph-compose-bundle renders a template, exposes the bundled fonts, and makes
  the colour-emoji set resolvable.

A dual-shell harness (run.sh / run.ps1) runs each project against a dedicated
local repository that never receives an install of GraphCompose, evicting the
graph-compose-* artifacts before each scenario so they must re-resolve from
Central; it prints per-scenario RESULT lines and a machine-readable SUMMARY.
Maven's own plugins stay cached (re-downloading them tests Maven, not the
release). Not wired into CI — run on demand around a release.

Tests: all six scenarios pass against the published 2.0.0 on Maven Central, both
warm and with GraphCompose evicted per scenario (graph-compose-core-2.0.0.jar
fetched from repo.maven.apache.org confirms Central resolution).

* test(release-smoke): pin Central-only resolution, add a dispatch workflow

- Isolated settings.xml (mirrorOf=*) forces every artifact and plugin request
  through Maven Central, passed to each scenario with -s, so a scenario can only
  pass if the coordinate is genuinely resolvable on Central.
- Hard-fail if the GraphCompose cache directory cannot be evicted, and confirm
  io/github/demchaav is gone before each scenario, so a stale cache can never mask
  a broken publish.
- Accept a version override (--version / -Version, default 2.0.0) passed as
  -Dgc.version; release smoke tests published artifacts only, never a SNAPSHOT.
- Add a workflow_dispatch workflow (.github/workflows/release-smoke.yml) that runs
  the harness manually with a version input.

Tests: all six scenarios pass against 2.0.0 on Maven Central through the
Central-only mirror with GraphCompose evicted per scenario
(SUMMARY {"version":"2.0.0","passed":6,"failed":0,"total":6}).
…lease (#397)

* build(release): pre-tag gates + automated post-release bump in cut-release

Automate the post-release version bump and gate the tag on the metadata and binary
compatibility that a stale README or an accidental break would otherwise slip past.

cut-release.ps1:
- -PostReleaseOnly now opens the next development line: bumps every train pom to the
  next patch -SNAPSHOT (idempotent — skipped when already a SNAPSHOT, and when there
  is no core/pom.xml) and restores the /blob/develop showcase links, leaving the
  README/showcase install snippets on the just-published release (the version guard
  requires snippets to advertise the version on Central during a -SNAPSHOT cycle).
- Fast pre-tag metadata gate (Step 2b): fails the cut if the CHANGELOG is not dated
  for the target, the README "Latest stable" prose block does not name it, the README
  install snippet lags, or a train pom's version is wrong. That prose block has no
  test guarding it, so this is the only automated guard against tagging with a stale
  release-status line; a dry run warns on it (the one check needing no mutation).
- Binary-compatibility gate (Step 5b): runs japicmp against the published baseline
  before commit/tag, independent of the PR-time CI gate. Skipped by -SkipVerify and
  on the legacy 1.x layout.
- Post-tag reminders point at the release-smoke suite (post-publish) and the
  -PostReleaseOnly follow-up.

release-process.md: document the new gates and the automated SNAPSHOT bump, the
post-publish release-smoke step, and a release-publication failure-recovery table
(failed GitHub Release, failed Central validation with the module deploy order,
partial publication, stale-tag documentation, and the patch-release criteria).

Verified via -DryRun of a full cut and of -PostReleaseOnly, the Assert-ReleaseMetadata
regexes against the real CHANGELOG/README, and Get-NextSnapshotVersion across final /
patch-carry / pre-release / already-SNAPSHOT inputs. No tag, no publish; project stays
on 2.0.1-SNAPSHOT.

* build(release): shared preflight, post-bump validation, publish resume

Close six release-safety gaps in the cut-release / publish tooling:

- Extract the branch / clean-tree (incl. staged) / origin-sync preflight into
  Assert-BranchPreflight and run it from both a real cut and -PostReleaseOnly, so the
  post-release path can no longer commit + push from the wrong branch, a dirty tree,
  or out of sync with origin.
- -PostReleaseOnly now runs `mvnw validate` + VersionConsistencyGuardTest after the
  SNAPSHOT bump, before committing/pushing. The Maven args go through splatted arrays,
  not inline: the call operator re-tokenizes an inline -Djacoco.skip=true at the dot
  into a bogus Maven phase.
- publish.yml gains a start_at choice input, a plan step, and per-module `if:` guards
  so a partial Central publication can resume from the first unpublished module. A full
  re-dispatch always starts at core and Central rejects re-uploading an already-validated
  coordinate, so it must not be blindly rerun — the recovery doc is corrected to match.
- Assert-ReleaseMetadata now fails when the graph-compose README install snippet is
  missing, not only when its version differs.
- New release-script-check.yml runs cut-release.ps1's dry-runs and a unit check of
  Get-NextSnapshotVersion on any change to the script (the main CI path filters skip it).
- Script help text documents that -PostReleaseOnly opens the next SNAPSHOT line.

Verified: both dry-runs exit 0; the splat passes -Djacoco.skip=true intact (inline
splits it); the publish plan-step start_at logic and the missing-snippet check tested.
No tag, no publish; develop stays 2.0.1-SNAPSHOT.

* build(release): guard fetch failures, validate start_at, order the stale-README check

Three release-safety fixes on top of the release-process hardening:

- Assert-BranchPreflight now checks the exit code of `git fetch` and both `git
  rev-parse` calls (capturing before .Trim() so a failure surfaces the real
  message, not a null-method error). A silently-failed fetch (network/auth) would
  otherwise compare against a stale origin ref and wrongly report the branch in
  sync — a real gap for a release script.
- publish.yml's deploy planner rejects an unknown start_at: an unrecognised value
  would leave every module skipped and publish nothing while the job stayed green.
  Empty (a tag-triggered run) still means "all".
- The README "Latest stable" check moves to Step 0, BEFORE any file is mutated
  (extracted into Test-ReadmeLatestStable). A stale line now aborts with a clean
  tree instead of failing at Step 2b after Steps 1-2 dirtied the tree — which the
  next preflight would then refuse to run over. Assert-ReleaseMetadata keeps the
  post-mutation checks (CHANGELOG date, install snippet, pom versions).

release-script-check.yml now runs the real Test-ReadmeLatestStable against the
actual README (not just a dry-run print), so the stale-tag guard's regex is
exercised in CI.

Verified: both dry-runs exit 0; the Step-0 Latest-stable warning fires before
Step 1; start_at accepts empty/all/<module> and rejects unknown values;
Test-ReadmeLatestStable matches the README's version and rejects a bogus one. No
tag, no publish; develop stays 2.0.1-SNAPSHOT.

* build(release): split final vs pre-release cut paths; ls-remote tag check

Two release-safety fixes:

- Pre-release path. The script supports X.Y.Z-rc.N / -alpha / -beta, but publish.yml
  never ships a hyphenated tag to Maven Central — pre-releases go only to the GitHub
  Release pre-release surface. So gate the Central-facing work on
  $isFinalRelease = $Version -match '^\d+\.\d+\.\d+$': only a final release checks the
  README 'Latest stable' block, rewrites the README / module / showcase install
  snippets, and validates them in Assert-ReleaseMetadata. A pre-release still bumps the
  train poms (the tag builds at that version) but leaves 'Latest stable' and the Central
  snippets on the last stable, on-Central version — rewriting them to an RC would
  advertise a coordinate that 404s for anyone who copies it. VersionConsistencyGuardTest
  matches: snippets must equal the pom only for a concrete final version; for a -SNAPSHOT
  or pre-release pom they must equal the latest published release.

- Origin-tag check. The check used `git fetch refs/tags/...`, which exits 128 for a
  legitimately-absent tag (the normal pre-cut case), so its exit code could never
  distinguish "tag free" from a network failure. Switched to `git ls-remote --tags`
  (empty output = free; non-zero = network/auth error), so a broken connection can no
  longer be mistaken for "tag is free".

release-script-check.yml adds a 2.1.0-rc.1 dry-run asserting the pre-release path (no
'Latest stable' check, no install-snippet bump).

Verified: final (2.0.2) and pre-release (2.1.0-rc.1) dry-runs both exit 0 with the
correct split; VersionConsistencyGuardTest 12/12; ls-remote distinguishes an absent tag
(exit 0, empty) from a network error. No tag, no publish; develop stays 2.0.1-SNAPSHOT.

* build(release): reject pre-release tags from Central; RC uses final release notes

Ensure a pre-release (X.Y.Z-rc.N / -alpha / -beta) never reaches Maven Central,
consistent with cut-release.ps1's final-vs-pre-release split.

- publish.yml: a manual workflow_dispatch bypassed the job `if:` (its first operand
  is unconditionally true for dispatch), so a dispatched pre-release tag could
  publish. Add a first-stage step that rejects any tag not matching ^vX.Y.Z$ (tag is
  passed via env, not inlined, to avoid ref-name injection).
- cut-release.ps1: validate the version up front against
  ^\d+\.\d+\.\d+(-(rc|alpha|beta)\.\d+)?$, so an arbitrary suffix like 2.1.0-preview.1
  is rejected rather than silently taken as a pre-release. Only print the "verify
  Maven Central" / "smoke published artifacts" reminders for a final release.
- release.yml: a pre-release has no CHANGELOG section of its own, so it now uses the
  upcoming final version's notes (NOTES_TAG=${TAG%%-*}) instead of a generic fallback.
- VersionConsistencyGuardTest.latestPublishedRelease(): restrict to a final semver
  header (\d+\.\d+\.\d+), so a dated pre-release header is never treated as the
  published Central version.
- release-script-check.yml: add a 2.1.0-preview.1 rejection assertion (trapping the
  script's terminating throw with try/catch — *>&1 does not catch a throw in-process).

Verified: final (2.0.2) and pre-release (2.1.0-rc.1) dry-runs exit 0; 2.1.0-preview.1
is rejected in-process; VersionConsistencyGuardTest 12/12; the publish tag guard
accepts v2.0.2 and rejects hyphenated/malformed tags; ${TAG%%-*} yields the final
tag; both workflow YAMLs valid. No tag, no publish; develop stays 2.0.1-SNAPSHOT.
The 2.0.1 development line carries no user-facing change — its only note was the
japicmp binary-compatibility enforcement, which is repo-internal tooling already
documented in docs/api-stability.md. Advertising a "v2.0.1 — Planned" release with
nothing installable is misleading, so drop the entry; the CHANGELOG top is the dated
v2.0.0 again. develop stays on 2.0.1-SNAPSHOT — the japicmp gate needs a working
version distinct from the 2.0.0 baseline — and a version entry is added when a real
user-facing change lands.
…chet (#400)

The graph-compose-coverage module produced a cross-module JaCoCo aggregate
report but enforced no threshold, so coverage could silently decline.

Add a non-regression ratchet on the aggregate (core + render-pdf + templates,
counting the qa cross-module exec). JaCoCo has no native aggregate-check goal,
so the check reproduces the aggregate inputs: unpack the measured modules'
classes, merge their execs, and run jacoco:check on the combined BUNDLE for
INSTRUCTION and BRANCH covered-ratio. The floors (0.875 / 0.68) sit just below
the current baseline (0.87857 / 0.68310, identical on Windows and CI Linux),
leaving only rounding and cross-platform headroom. The check runs in the
existing build-and-test verify step, which feeds the required CI Gate, so a
coverage regression fails the PR with no new CI job.
@DemchaAV DemchaAV merged commit ace8d37 into main Jul 13, 2026
24 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant