build: make Java 25 the default, demote Java 21 to the variant

[sfreudenthaler]

What

Make Java 25 the default for all builds and for the published dotcms/dotcms:latest image, and demote Java 21 to the parallel variant (…_java-21).

This is a single source-of-truth change:

File	Change
.sdkmanrc	java=21.0.8-ms → java=25.0.2-ms
docker/java-base/Dockerfile	default ARG SDKMAN_JAVA_VERSION → 25.0.2-ms (cosmetic; callers always pass the arg)
cicd_8-manual-deploy.yml	fix stale "default Java 21" doc string → "default Java 25"

Why this is all that's needed (no workflow tag-logic changes)

The latest tag is gated in cicd_comp_deployment-phase.yml on inputs.latest && docker_suffix == ''. The primary release build (cicd_6-release.yml) reads its Java version from .sdkmanrc and has an empty suffix, so once .sdkmanrc says Java 25, the primary build ships Java 25 and automatically wins latest (and, via cicd_weekly-rolling-tags.yml, weekly). The Java 21 build moves to the variant pathway (cicd_7-release-java-variant.yml) and ships under …_java-21 + the floating java-21 tag.

dotcms/java-base:25.0.2-ms already exists on Docker Hub (the Java 25 variant has been building against it), so the base-image path (FROM dotcms/java-base:${SDKMAN_JAVA_VERSION}) is already proven.

⚠️ Required companion change at merge time (repo variables, not in this PR)

Repo variables are GitHub settings, so they can't live in the PR. At merge, flip them so the variant builds Java 21 instead of Java 25:

RELEASE_JAVA_VARIANT_VERSION:  25.0.2-ms  →  21.0.8-ms
RELEASE_JAVA_VARIANT_SUFFIX:   java-25    →  java-21

If .sdkmanrc is merged but the vars are not flipped: the variant would also build Java 25 (duplicate of latest), and no Java 21 image would be produced — breaking consumers still pinned to Java 21. They must change together.

Resulting tags after merge + var flip

• dotcms/dotcms:latest, :weekly, :{version} → Java 25
• dotcms/dotcms:java-21, :{version}_java-21 → Java 21 (transition support)

Rollout

• Draft for now. Keep today's behavior (Java 21 default, Java 25 variant, latest = Java 21) for ~2–3 weeks.
• Flip: mark ready + merge and flip the two repo variables together.
• Retire (end of July): fully retire the Java 21 variant — disable the cicd_7-release-java-variant.yml trigger / unset the variant repo vars (separate follow-up).

🤖 Generated with Claude Code

[github-actions]

❌ Issue Linking Required

This PR could not be linked to an issue. All PRs must be linked to an issue for tracking purposes.

How to fix this:

Option 1: Add keyword to PR body (Recommended - auto-removes this comment)
Edit this PR description and add one of these lines:

• This PR fixes #123 or Fixes: #123

• This PR closes #123 or Closes: #123

• This PR resolves #123 or Resolves: #123

• Other supported keywords: fix, fixed, close, closed, resolve, resolved
  Option 2: Link via GitHub UI (Note: won't clear the failed check)

1. Go to the PR → Development section (right sidebar)

2. Click "Link issue" and select an existing issue

3. Push a new commit or re-run the workflow to clear the failed check
   Option 3: Use branch naming
   Create a new branch with one of these patterns:

• 123-feature-description (number at start)

• issue-123-feature-description (issue-number at start)

• feature-issue-123 (issue-number anywhere)

Why is this required?

Issue linking ensures proper tracking, documentation, and helps maintain project history. It connects your code changes to the problem they solve.---

This comment was automatically generated by the issue linking workflow

[claude]

Claude finished @sfreudenthaler's task in 1m 40s —— View job

---

PR Review: build: make Java 25 the default, demote Java 21 to the variant

• Read changed files
• Review CI/CD workflow logic
• Check for stale references

---

The diff itself is clean — 3 lines changed across 3 files, all consistent with the stated goal.

Two issues worth flagging:

1. cicd_8-manual-deploy.yml example version is wrong (line 85)
The updated description reads:

'Override Java version (SDKMAN format, e.g., 21.0.8-ms). Leave empty to use default Java 25 from .sdkmanrc.'

The example 21.0.8-ms is the old default. It should be updated to an override scenario that makes sense — either 21.0.8-ms with a note that it's the override-to-old-version example (intentional), or flipped to a more neutral example. As written it's confusing: the description says "e.g., 21.0.8-ms" but that's now the variant version, not a natural override example. Not a blocker, but misleading to future users.

2. CLAUDE.md and docs still reference Java 21 as the runtime/default

Not in this PR's scope, but worth noting — CLAUDE.md line 24 still says sdk env install # Java 21 via SDKMAN, and lines 66/89 say "Java 21 runtime". docs/core/ARCHITECTURE_OVERVIEW.md line 6 also says "Java 21 runtime". These will be stale after merge. Should be updated in a follow-up (or this PR).

3. Atomicity risk (acknowledged in PR body but worth emphasizing)
The PR correctly calls out that .sdkmanrc merge + repo variable flip must be atomic. If there's any gap between merge and the variable flip (RELEASE_JAVA_VARIANT_VERSION, RELEASE_JAVA_VARIANT_SUFFIX), a release triggered in that window would produce two Java 25 images and zero Java 21 images. Since this PR is marked draft, that risk is managed — just ensure the flip happens in the same operation as marking ready and merging.

No logic bugs found in the workflow tag routing rationale.

[sfreudenthaler]

close this out in favour of #35914

[sfreudenthaler]

duplicates #35914