chore(QTDI-3301): Switch TCK release versions to calendar scheme

[lxia-talend]

Requirements

• Any code change adding any logic MUST be tested through a unit test executed with the default build
• Any API addition MUST be done with a documentation update if relevant

Not applicable: this PR contains no Java source and no product logic — only Maven version
strings, one Jenkinsfile and two release shell scripts. The changed logic (release version
derivation) is verified by dedicated harnesses, see How this was verified below.

Why this PR is needed?

Jira: QTDI-3301

TCK releases use a plain incremental scheme (1.96.0) while Connectors already use calendar
versioning (1.<YYMM>.<patch>, e.g. connectors/1.2609.0). Stakeholders cannot tell from a TCK
version which release train it belongs to.

This PR switches TCK to the same MAJOR.YEARMONTH.PATCH scheme, starting with 1.2610.0 for the
September release (TCK releases M-1, so September produces the 2610 line targeting the Studio
October release).

What does this PR adds (design/code thoughts)?

#	Change	File(s)
1	Cut master over from 1.96.0-SNAPSHOT to 1.2610.0-SNAPSHOT (mvn versions:set, 86 poms)	pom.xml + 85 module poms
2	Delegate release version arithmetic to the VersionController shared library already loaded by the pipeline — the same implementation Connectors use — instead of local string math	ci/Jenkinsfile-release
3	Handle the December → January rollover: 1.2612.0 → 1.2701.0-SNAPSHOT (not 1.2613.0)	ci/Jenkinsfile-release, .jenkins/scripts/release_legacy.sh
4	Add a DRY_RUN parameter: runs release:prepare -DdryRun=true and skips every publishing stage, so a full release can be rehearsed without tagging, pushing or deploying	ci/Jenkinsfile-release, .jenkins/scripts/release/release-2-prepare.sh
5	Archive the dry-run evidence (pom.xml.tag, pom.xml.next, release.properties) and release:clean afterwards, so a rehearsal proves the computed versions and cannot leave a resumable state behind	ci/Jenkinsfile-release

Design notes

• get_release_info() changed from static to an instance method — a static method cannot resolve a
  shared-library global var from the script binding.
• The shared library is version-pinned (tqa-e2e-tests-tool@v2.4.2-ttp2), so the new
  VersionController calls cannot drift under the job.
• .jenkins/scripts/release_legacy.sh keeps its own copy of the bump logic (it does not run under
  Jenkins shared libraries); the December → January defect is fixed there too and the two copies were
  verified to be behaviourally identical. A comment points at
  VersionController.getSnapshotVersion as the source of truth.
• Backward compatible: in-flight maintenance/1.9x branches keep working — the legacy 1.9x
  scheme is still derived correctly.

How this was verified

#	Verification	Result
V1	mvn -B validate -DskipTests over the full 89-module reactor — model building, parent resolution, inter-module dependency coherence	✅ PASS
V2	grep for any remaining 1.96.0-SNAPSHOT in poms	✅ 0 hits
V3	Version derivation harness running the real VersionManager.groovy from the pinned shared library — GA, maintenance, Dec→Jan rollover, legacy 1.9x	✅ 5/5 PASS
V4	Legacy bash bump harness, including the 1.12.0 → 1.13.0 non-rollover guard for 2-digit minors	✅ 6/6 PASS
V5	ci/Jenkinsfile-release Groovy CompilationUnit parse	✅ PARSE OK
V6	bash -n on both changed scripts	✅ OK
V7	tdi-jenkins-job / TTP version-format audit — no hardcoded version-format assumption found	✅ no change needed

V3 output (row 2 is the December → January rollover; rows 4–5 prove legacy compatibility):

PASS | 1.2610.0-SNAPSHOT | GA          | [1.2610.0, 1.2611.0-SNAPSHOT, 1.2610.1-SNAPSHOT, maintenance/1.2610]
PASS | 1.2612.0-SNAPSHOT | GA          | [1.2612.0, 1.2701.0-SNAPSHOT, 1.2612.1-SNAPSHOT, maintenance/1.2612]
PASS | 1.2610.1-SNAPSHOT | MAINTENANCE | [1.2610.1, 1.2610.2-SNAPSHOT, 1.2610.2-SNAPSHOT, maintenance/1.2610]
PASS | 1.95.1-SNAPSHOT   | MAINTENANCE | [1.95.1,   1.95.2-SNAPSHOT,   1.95.2-SNAPSHOT,   maintenance/1.95]
PASS | 1.96.0-SNAPSHOT   | GA          | [1.96.0,   1.97.0-SNAPSHOT,   1.96.1-SNAPSHOT,   maintenance/1.96]

Suggested reviewer validation: trigger Jenkinsfile-release on this branch with DRY_RUN=true
and check the archived pom.xml.tag / pom.xml.next / release.properties.

Known, out-of-scope observations

Reported here rather than fixed, per scope discipline — each needs its own ticket:

1. component-runtime-beam does not compile on unmodified master
   (package org.apache.commons.compress.utils does not exist). Reproduced with this branch's poms
   stashed, so it is pre-existing and unrelated to the version cutover. This is why the reactor-wide
   check above is mvn validate rather than mvn install.
2. documentation/src/main/frontend/package.json declares 1.91.0-SNAPSHOT while its
   package-lock.json declares 1.96.0-SNAPSHOT. Pre-existing drift; package.json is
   Maven-filtered at build time so the committed value is inert.

Follow-up not covered here

The ticket's nice-to-have — naming TCK Jira release versions tck/1.2610.0 instead of the bare
version — is a Jira administration action, not a code change, and is out of this PR's scope.

AI contribution metrics

• Code Generation % (this PR): 100%
• Code Generation % (ticket-wide cumulative): 100%
• Technical Design % (ticket-wide cumulative): 100%

AI generated code

https://internal.qlik.dev/general/ways-of-working/code-reviews/#guidelines-for-ai-generated-code

• this PR has been written with the help of GitHub Copilot or another generative AI tool

[lxia-talend]

🔍 Scope & Design Review (critique-implementation)

Adversarial self-review run before the PR was opened. All rounds included.

Adversarial self-review of commit c97e7bcfd5f (+ Round 1 fixes) on
lxia-talend/QTDI-3301_switch_tck_to_calendar_versioning.

Target list: 86 poms (mechanical versions:set, reviewed as a class), ci/Jenkinsfile-release,
.jenkins/scripts/release/release-2-prepare.sh, .jenkins/scripts/release_legacy.sh.

Critic Round 1 — Findings

#	Severity	File	Description	Suggested Fix
1	MAJOR	ci/Jenkinsfile-release	post { always } of Maven release prepare archives **/*pom.xml. With -DdryRun=true the release plugin never rewrites pom.xml in place — it writes pom.xml.tag / pom.xml.next / release.properties. A DRY_RUN therefore archives the unchanged poms, so the artifact that would prove the calendar version rewrite is correct is never captured. This defeats the stated purpose of the new parameter (dev's R4 request).	Add a DRY_RUN-only archiveArtifacts for **/pom.xml.tag, **/pom.xml.next, release.properties
2	MINOR	ci/Jenkinsfile-release	A dry run leaves release.properties + pom.xml.* behind (release:clean is only reached via the skipped Maven release process stage). Pods are ephemeral so the practical risk is low, but in any reused workspace the next release:prepare would resume the simulated release instead of starting fresh.	Run mvn release:clean at the end of the dry run
3	MINOR	ci/Jenkinsfile-release	The manual input gate in Version validation says "You will do a GA release" with no mention of DRY_RUN — an approver reading only the prompt cannot tell a rehearsal from a real release.	Mention DRY_RUN in checkMsg
4	MINOR	.jenkins/scripts/release_legacy.sh	The new comment names ci/Jenkinsfile-release as the source of truth, but that file now delegates to VersionController — the comment points one hop short.	Point at VersionController.getSnapshotVersion
5	INFO	ci/Jenkinsfile-release	assemblyExtraBuildParams now forces scm.repository=$params.FAKE_REPOSITORY when dryRun. Harmless (dry run never pushes) and it is defence in depth, but it couples DRY_RUN to a param a user could blank. Pre-existing pattern for FAKE_RELEASE.	No change — accepted

Approval gate: REJECTED — 1 Major must be resolved before PR creation.

Challenges raised and cleared (no finding)

Challenge	Verdict
Is VersionController actually resolvable? It is used nowhere else in this repo.	✅ Confirmed present as vars/VersionController.groovy at the pinned tqa-e2e-tests-tool@v2.4.2-ttp2 (line 19 getSnapshotVersion, line 28 getMaintenanceBranchName) — same library that already provides JenkinsStatusController
get_release_info was static; a static method cannot resolve a shared-library global var from the script binding.	✅ Correctly changed to an instance method in the same commit
writeFile 'target/…' — does the parent dir exist, and does it dirty the SCM tree that release:prepare inspects?	✅ writeFile creates parents; target is line 2 of .gitignore. Archived before preparationGoals=clean verify can wipe it
Does build-helper:parse-version (used by documentation/pom.xml, images/pom.xml) survive a 4-digit minor?	✅ 1.2610.0-SNAPSHOT → major 1 / minor 2610 / incremental 0 under DefaultArtifactVersion
Are there tracked files still hardcoding 1.96.0 (antora.yml, package.json, generated adoc)?	✅ All are Maven-filtered in place at process-sources (documentation/pom.xml filter-antora) and re-committed by release-5-prepare-next-iteration.sh; nothing to bump by hand
Do release-5 / release-6 assume a version format?	✅ Both are format-agnostic (versions:set with a passed-in value)
Does Maven version ordering still increase, 1.96.0 → 1.2610.0?	✅ Minor compared numerically: 2610 > 96
Legacy bash guard ${#min} -eq 4 && ${min} == *12 vs library minor.size() == 4 && endsWith("12")	✅ Logically identical — the two copies are in sync; 1.12.0 → 1.13.0 proves 2-digit minors do not roll over
Maintenance path: is nextVersion == maintenanceVersion correct?	✅ Matches the pre-change behaviour (rev + 1) exactly
maintenanceBranch now always computed (was empty string for maintenance releases)	✅ Only consumed by Create maintenance branch, gated on isMasterBranch && ACTION == GA

Round 1 fixes applied

• Finding 1 — DRY_RUN-only archiveArtifacts for **/pom.xml.tag, **/pom.xml.next, release.properties (allowEmptyArchive: true).
• Finding 2 — mvn release:clean after that archive, via sh(returnStatus: true) so cleanup can never fail the build.
• Finding 3 — checkMsg now renders as a **DRY RUN** (nothing published).
• Finding 4 — comment retargeted at VersionController.getSnapshotVersion.

Re-verification after the fixes:

Check	Result
ci/Jenkinsfile-release Groovy parse (CompilationUnit → Phases.CONVERSION)	✅ PARSE OK
VerifyReleaseInfo.groovy against the real VersionManager	✅ 5/5 PASS
verify_legacy_bump.sh	✅ 6/6 PASS
bash -n on both changed scripts	✅ OK

Critic Round 2 — Findings

Re-review of the four fixes only (no other file changed since Round 1).

• Comma-separated Ant patterns in a single archiveArtifacts — supported.
• sh inside script {} inside a stage-level post { always {} } — valid declarative syntax; runs on the same kubernetes agent / main container.
• Ordering is correct: archive first, clean second, so the evidence is captured before the working files are removed.
• returnStatus: true prevents a cleanup failure from failing an otherwise successful dry run.
• The nested ternary inside the triple-quoted checkMsg GString parses correctly (confirmed by the Groovy parse check).

No Blocker or Major findings.

Approval gate: APPROVED — no Blocker or Major findings. Round 1 Minors 2–4 fixed; INFO 5 accepted as-is.

Final verdict

APPROVED after 2 rounds (limit 3). 1 Major found and fixed, 3 Minors found and fixed, 1 INFO
accepted. No unresolved findings carried into the PR.

---

Signed: Claude Opus 5

[lxia-talend]

✅ Compliance Report (review-changes)

Objective rule-compliance review of every file changed on
lxia-talend/QTDI-3301_switch_tck_to_calendar_versioning vs origin/master
(commits c97e7bcfd5f + c19660bec54).

Rule sources: core-rules.md, git-branch-and-commit.md. The java-* / tck-* topics do not
apply — the diff contains no Java source, no connector code and no test source (build/CI only).

Changed-file checklist — 89 files, all reviewed

#	File(s)	Type	Verdict
1	pom.xml + 85 module pom.xml	build	✅ PASS
2	ci/Jenkinsfile-release	CI (Groovy)	✅ PASS (2 Warnings)
3	.jenkins/scripts/release/release-2-prepare.sh	CI (Bash)	✅ PASS
4	.jenkins/scripts/release_legacy.sh	CI (Bash)	✅ PASS (1 Info)

1 — the 86 poms

• Diff is exclusively version lines: filtering the diff for anything other than
  1.96.0-SNAPSHOT / 1.2610.0-SNAPSHOT returns zero lines. No stray reformatting, no
  dependency edits, no license-header churn.
• git grep "1\.96\.0-SNAPSHOT" -- '*.xml' → 0 hits: no module left on the old version, no
  orphaned <parent><version>.
• Generated by mvn versions:set, so parent/child coherence is tool-guaranteed and was
  independently confirmed by mvn validate across all 89 modules.

2 — ci/Jenkinsfile-release

• Apache license header intact.
• New booleanParam(DRY_RUN) sits in the existing separator-delimited debug section, matching the
  surrounding style; defaultValue: false is the safe default.
• when { expression { !params.DRY_RUN } } added to every publishing stage — Maven release
  process, Release studio modules, Release Docker image, Prepare next iteration, Create
  maintenance branch. Enumerated against the full stage list; no publishing stage was missed.
• get_release_info Javadoc updated in step with the signature change (static → instance) and the
  return-value semantics.
• Shared library is version-pinned (lib("tqa-e2e-tests-tool@v2.4.2-ttp2")), so the new
  VersionController calls cannot drift under the job.

3 — .jenkins/scripts/release/release-2-prepare.sh

• Apache license header and set -xe unchanged.
• DRY_RUN documented in the existing parameter comment block, in the file's own style.
• "${DRY_RUN:-false}" defaults safely, and dryRunParams=() expanded as "${dryRunParams[@]}"
  keeps the no-op case a genuine no-op — consistent with how extraBuildParams is already handled.
• bash -n clean.

4 — .jenkins/scripts/release_legacy.sh

• Guard [[ ${#min} -eq 4 && ${min} == *12 ]] is quoted/bracketed correctly; bash -n clean.
• Behaviour matches the shared library exactly (6/6 harness cases, including the 1.12.0 → 1.13.0
  non-rollover case that proves 2-digit minors are untouched).

Findings

#	Severity	File	Description	Status
1	Warning	ci/Jenkinsfile-release	release:prepare -DdryRun=true leaves the computed versions in pom.xml.tag / pom.xml.next, which the existing **/*pom.xml archive pattern does not match — a dry run would have published no usable evidence.	FIXED in c19660bec54 — DRY_RUN-only archiveArtifacts for **/pom.xml.tag, **/pom.xml.next, release.properties
2	Warning	ci/Jenkinsfile-release	Dry-run leftovers (release.properties, pom.xml.*) were never cleaned, so a reused workspace could resume the simulated release.	FIXED in c19660bec54 — mvn release:clean via sh(returnStatus: true)
3	Info	ci/Jenkinsfile-release	The manual input prompt did not distinguish a rehearsal from a real release.	FIXED in c19660bec54
4	Info	.jenkins/scripts/release_legacy.sh	"Source of truth" comment pointed at the Jenkinsfile, which now itself delegates.	FIXED in c19660bec54
5	Info	repo-wide	component-runtime-beam does not compile on unmodified master (package org.apache.commons.compress.utils does not exist). Pre-existing and unrelated; left alone per core-rules.md §4 scope discipline.	Not fixed — needs its own ticket
6	Info	documentation/src/main/frontend/package.json	Declares 1.91.0-SNAPSHOT while package-lock.json declares 1.96.0-SNAPSHOT. Pre-existing drift; package.json is Maven-filtered at build time so the committed value is inert. Out of scope.	Not fixed — pre-existing

Severity counts: Critical fixed: 0 · Warnings: 2 (both fixed) · Info: 4 (2 fixed, 2 pre-existing
and out of scope).

Convention compliance

Rule (git-branch-and-commit.md)	Value	Verdict
Branch username/JIRA-ID_short_description	lxia-talend/QTDI-3301_switch_tck_to_calendar_versioning	✅ real GitHub login, mandatory QTDI-3301, lowercase + underscores, no @
Commit <type>(<scope>): <subject>	chore(QTDI-3301): Switch TCK release versions to calendar scheme (63 ch) · chore(QTDI-3301): Archive and clean the dry run release files (61 ch)	✅ chore correct for build/CI with no functional product change; capitalized, imperative, no trailing period
Body wrapped at 72, explains what/why	both commits	✅
Co-authored-by: per AI tool	both commits	✅

Rule (core-rules.md)	Verdict
§2 Jira — comment only, no field edits or transitions	✅ comments 1205688, 1205690, 1205713, 1205807 only
§3 GitHub — nothing pushed before agent 05	✅ both commits local only
§4 Scope discipline — no unrelated fixes	✅ pre-existing beam breakage deliberately left alone (Info 5)

Spotless: not applicable — spotless-maven-plugin is declared only in root <pluginManagement> with
no format configuration or execution binding, and the diff contains no Java source.

Verdict

PASS — no Critical findings. Both Warnings were fixed and re-verified (Groovy parse OK, 5/5
version-derivation cases, 6/6 legacy-bump cases, bash -n clean). Info 5 and 6 are pre-existing and
carried into the PR description as known, out-of-scope observations.

---

Signed: Claude Opus 5

[sonar-rnd]

Quality Gate passed

Issues

• 0 New Issues
• 0 Fixed Issues
• 0 Accepted Issues

Measures

• 0 Security Hotspots
• No data about coverage (63.30% Estimated after merge)
• 0.00% Duplicated Code (1.40% Estimated after merge)

Project ID: org.talend.sdk.component:component-runtime

View in SonarQube