[JosteinGj]

Why

The Java SDK and the platform live in the same repository, and since #148 both would use vX.Y.Z tags:

• The platform releases from one branch per minor version, release/vX.Y (ci: run checks on release/vX.Y branches #145), with tags vX.Y.Z. The first is meant to be v1.0.0.
• The SDK publishes to Maven Central on every published GitHub Release tagged vX.Y.Z (build(sdk): make datahub-sdk publishable to Maven Central, with locally signed, CI-verified releases #148).

So the day the platform cuts its v1.0.0 release, the SDK workflow starts and tries to publish Java SDK 1.0.0. If javaSdkVersion isn't 1.0.0, the platform release shows a failed check. If it is, the SDK goes to Central whether or not anyone meant to release it, and a Central release is permanent. The two version lines are also unrelated today: the SDK is heading for 0.3.0 while the platform is heading for 1.0.0.

This keeps the two separate but alike:

	Branch	Tag
Platform	release/vX.Y	vX.Y.Z
Java SDK	release/sdk-vX.Y	sdk-vX.Y.Z

What changes

.github/workflows/java-sdk-release.yml:

• Only SDK releases run it. On a release event, the first job runs only when the tag starts with sdk-v, and every other job depends on it. So a platform release shows a skipped run, never a failed one, and can never publish the SDK.
• The tag must be sdk-vX.Y.Z and match both apiModelVersion and javaSdkVersion, as before.
• The tagged commit must be on release/sdk-vX.Y. Releases come from the SDK's release branch, the way the platform's come from its own, not from wherever the tag happens to point. This was pushed to build(sdk): make datahub-sdk publishable to Maven Central, with locally signed, CI-verified releases #148's branch after it merged (c3729169) and never reached main. It lands here, adapted to the new names.
• The version stripped from the tag for verifying and uploading follows the new prefix.

The SDK release branches sit under release/, so the existing build.yml, dco.yml and e2e.yml triggers (release/**) already run on pull requests into them. e2e.yml's release-line resolver matches only release/vX.Y, so a pull request into release/sdk-vX.Y tests against the Rust SDK's main, the same as a pull request into main. That is right, because the Java SDK's release line doesn't follow a platform version.

AGENTS.md's release section now describes the two schemes side by side and the SDK steps:

# on release/sdk-vX.Y, with both versions set to X.Y.Z
./gradlew centralBundle -PsigningUseGpgCommand=true
gh release create sdk-vX.Y.Z --target release/sdk-vX.Y --latest=false build/central/datahub-central-X.Y.Z.zip

--latest=false keeps the repository's "latest release" badge pointing at the platform.

Needed in the GitHub settings

Not code. The release environment as configured today:

• Its tag rule is v*, which is the platform's scheme, so an sdk-v* run could not get the Central token. Change it to sdk-v*.
• It has no required reviewers. The publish job would upload with no approval, and a Central release cannot be undone. Add at least one.
• Admin bypass is on. Turn it off, so the approval applies to everyone.

Also worth doing: a branch ruleset on release/* (still open from #145), since "the commit is on the release branch" is only as strong as who can push to it. Add a tag ruleset on sdk-v* and v* restricting who can create them.

Docs

• datahub-sdk-docs: none until the first release. Install snippets then point at the released version.
• datahub-docs (operators): no change.

Verification

• YAML parses.
• The version and branch check was run in a scratch repository. sdk-v0.3.0 on release/sdk-v0.3 passes. sdk-v0.3.0 on a commit not on that branch, a platform v0.3.0 tag, and an old-style java-sdk-v0.3.0 tag are all refused.
• A platform tag never reaches that check on GitHub, because the job-level condition skips the run first.
• The if: skip itself runs only on a real release event, so it is exercised by the first platform or SDK release.

🤖 Generated with Claude Code

[JosteinGj]

Superseded by #152: the platform and the Java SDK are now released together from one vX.Y.Z release, instead of on separate sdk-vX.Y.Z tags. Splitting them later would revive this scheme.