What changed
These rules apply to unlabelled semantic versions only (for example1.2.3). Labelled versions (such as 1.2.3-beta or 0.0.0-my-feature) are not part of these checks.
When you push a new unlabelled version, the platform validates two things in addition to existing format checks.
1. You cannot skip a required predecessor
The API must see the right previous unlabelled release before it accepts the new one:- Patch bump (
1.2.3): the exact unlabelled1.2.2must already exist. - Minor bump (
1.3.0): at least one unlabelled1.2.xmust exist. - Major bump (
2.0.0when coming from1.x): at least one unlabelled1.x.xmust exist.
1.0.0 is unchanged: there is no prior semver to require.
If the predecessor is missing, push fails with 403 and guidance like: Version X requires Y to exist. Push version Y, then try again.
2. You cannot insert an “intermediate” version behind a newer line
You also cannot push a version if a newer unlabelled version already exists in the segment that would make yours a backward insert:1.2.3: blocked if any unlabelled1.2.4or higher on the same1.2.*line already exists. Pushing1.3.0is still allowed when only1.3.xor2.x.xexists—those are not on the1.2.*patch line.1.3.0: blocked if any unlabelled1.4.xor higher on the same major (1.*) already exists.2.0.0is still allowed when only2.x.xexists.2.0.0: blocked if any unlabelled3.x.xor higher already exists.
What this means for you
- Plan patch → patch → minor → major (or the minimal chain your history needs) using unlabelled semver when you are ready to record real releases; use labelled snapshots while iterating.
- If you are stuck because old versions were removed, you may still use deprecation and, when appropriate, delete a deprecated version so your remaining unlabelled history matches what you want to push next.