papegaaij opened a new pull request, #1597:
URL: https://github.com/apache/wicket/pull/1597
## Problem
The japicmp baseline was hardcoded as the project's own snapshot:
```xml
<version>11.0.0-SNAPSHOT</version>
```
So every build on master compared a module against whatever
`11.0.0-SNAPSHOT` happened to sit in the local or remote repository — last
night's CI artifact, or the jar installed an hour ago. On the line where API
changes are allowed, that comparison is not just permissive, it is arbitrary:
it fails the build on changes master explicitly permits, depending on what was
installed last.
## Fix
The branch already carries the information the check needs: the major
version. The first release of a line is `<major>.0.0`, and that artifact exists
exactly on the branches where the check should run.
```xml
<version>${project.artifact.selectedVersion.majorVersion}.0.0</version>
```
- `master` (11.0.0-SNAPSHOT) → baseline `11.0.0`, never released → no
comparison, japicmp only warns.
- `wicket-10.x` (10.12.0-SNAPSHOT) → baseline `10.0.0` — what that branch
hardcodes today.
- `wicket-9.x` → `9.0.0`, likewise identical to its current value.
Nothing has to be edited when a line is released or branched. Releasing
10.12.0 keeps the baseline at 10.0.0. When 11.0.0 ships, the maintenance branch
(11.0.1-SNAPSHOT) starts enforcing against 11.0.0 by itself, and once master
bumps to 12.0.0-SNAPSHOT it goes quiet again. The expression is evaluated by
Maven's plugin parameter evaluator, so no extra plugin is needed and it works
offline.
`ignoreMissingOldVersion` is set explicitly. Both 0.25.4 and 0.26.1 already
only warn on an unresolvable baseline, so it changes nothing today; it keeps a
later plugin version from turning that warning into a build failure on the
development line.
## Verification
- `mvn clean verify -DskipTests -Pfast` over the full reactor on master:
green. Every jar module logs the "no resolvable old version" warning; the
`japicmp.skip` modules stay silent.
- The same change applied in a scratch worktree of `wicket-10.x`:
`japicmp.diff` reports `Comparing ... against .../wicket-util-10.0.0.jar`, so
the derived baseline resolves exactly as the hardcoded one did.
- In that worktree, making `Strings.afterFirstPathComponent` private fails
the build with `METHOD_LESS_ACCESSIBLE`. The check is still live on a
maintenance branch; `ignoreMissingOldVersion` does not neuter it.
## Costs
Master now logs one "Please provide at least one resolvable old version"
warning per jar module per build — honest, in that it says no check ran, but
noisier than before.
On a maintenance branch, a baseline that cannot be *downloaded* is
indistinguishable from one that does not exist, so the check would silently
pass. That was already true before this change.
`AGENTS.md` described the old `11.0.0-SNAPSHOT` behaviour and is updated to
match.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
