Description
The current SDK publishing workflow (deploy-javascript-sdk action) derives the version to publish by scanning all packages in core-web/libs/sdk/ and picking the highest latest and next dist-tags from NPM across all packages. This global versioning assumption breaks whenever packages drift out of sync.
Current problems:
@dotcms/react has next=1.2.6-next.3 while all others are at next=1.2.5-next.7- When the action calculates the next version,
HIGHEST_NEXT=1.2.6-next.3 but HIGHEST_STABLE=1.2.5 — base mismatch causes the suffix to reset to .1, colliding with already-published 1.2.5-next.1
- New packages (e.g.
create-app) have no next tag yet, causing the same collision
- ~150 lines of fragile version detection logic that still gets it wrong
Root cause: The system assumes global version sync but does not enforce it.
Acceptance Criteria
Additional Context
Immediate trigger: adding @dotcms/create-app to the SDK libs caused repeated 403 publish failures because its package.json version (1.0.0) was out of sync with the rest (1.2.5), and the auto-detection logic could not recover gracefully.
Related fix already merged: #35107 (sync create-app to 1.2.5)
The next tag suffix collision happens because get_next_patch_number() resets to 1 when the base version changes, but does not check whether {base}-next.1 is already published on NPM.
Description
The current SDK publishing workflow (
deploy-javascript-sdkaction) derives the version to publish by scanning all packages incore-web/libs/sdk/and picking the highestlatestandnextdist-tags from NPM across all packages. This global versioning assumption breaks whenever packages drift out of sync.Current problems:
@dotcms/reacthasnext=1.2.6-next.3while all others are atnext=1.2.5-next.7HIGHEST_NEXT=1.2.6-next.3butHIGHEST_STABLE=1.2.5— base mismatch causes the suffix to reset to.1, colliding with already-published1.2.5-next.1create-app) have nonexttag yet, causing the same collisionRoot cause: The system assumes global version sync but does not enforce it.
Acceptance Criteria
core-web/libs/sdk/VERSIONfile as the one source of truth for the SDK versiondeploy-javascript-sdkaction reads the version fromVERSIONinstead of scanning NPM dist-tagsnexttag suffix usesGITHUB_RUN_NUMBERinstead of incrementing logic — guaranteed unique, no collision possiblelibs/sdk/work automatically without manual version syncingVERSION(visible in history)cicd_manual-release-sdks.ymlbumps theVERSIONfile instead of computing versions from NPMAdditional Context
Immediate trigger: adding
@dotcms/create-appto the SDK libs caused repeated 403 publish failures because itspackage.jsonversion (1.0.0) was out of sync with the rest (1.2.5), and the auto-detection logic could not recover gracefully.Related fix already merged: #35107 (sync create-app to 1.2.5)
The
nexttag suffix collision happens becauseget_next_patch_number()resets to1when the base version changes, but does not check whether{base}-next.1is already published on NPM.