You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hitting this from the other direction: the 4-digit scheme doesn't just break npm, it breaks Prisma, and /ship re-breaks it automatically.
prisma generate parses package.jsonversion as strict SemVer and aborts:
Error: Invalid version: "1.0.0.1"
The workaround is what @-the-reporter did — let the two files carry different formats:
File
Format
Consumer
VERSION
1.0.0.2 (4-digit)
gstack /ship
package.json
1.0.2 (SemVer)
Prisma / npm
But that workaround doesn't survive the next ship. bin/gstack-version-bump dual-writes the same 4-digit string into both files unconditionally, and there's no opt-out:
Flag parsing only recognizes --version and --version-path. So on a repo that has deliberately split the formats, classify reports DRIFT_UNEXPECTED and write silently reintroduces the invalid version — putting the broken deploy back. Ship's own SKILL.md tells the agent to STOP on DRIFT_UNEXPECTED, which is correct, but there's then no supported way forward except hand-editing both files and bypassing the tool.
Two things that would fix it:
A --no-package-json flag (or a version_sync_package_json: false config key) so write/repair leave package.json alone.
Teach classify that a deliberate 4-digit/3-digit split is a valid state, not DRIFT_UNEXPECTED.
Happy to send a PR for (1) if that's the direction you'd want.
@16francej — recommend closing this issue as a duplicate of #1474. The strict-SemVer failure is one part of the broader release-identity problem, and a local exception would leave package, tag, changelog, and release behavior inconsistent. Preserve the reproduction and ensure #1474 covers package-version mapping or a no-mirror mode.
/ship still keeps the 4-digit VERSION file, but it now writes the npm-valid 3-digit translation into package.json (probe on main: gstack-version-bump write --version 0.1.1.0 wrote VERSION 0.1.1.0 and package.json "0.1.1"), so npm and Prisma no longer see a 4-part version. Fixed in v1.67.0.0 (#2604).
If you still see this on the latest gstack, please reopen with details.
Activity
travisbotello commentedon Jul 14, 2026
Hitting this from the other direction: the 4-digit scheme doesn't just break
npm, it breaks Prisma, and/shipre-breaks it automatically.prisma generateparsespackage.jsonversionas strict SemVer and aborts:The workaround is what @-the-reporter did — let the two files carry different formats:
VERSION1.0.0.2(4-digit)package.json1.0.2(SemVer)But that workaround doesn't survive the next ship.
bin/gstack-version-bumpdual-writes the same 4-digit string into both files unconditionally, and there's no opt-out:Flag parsing only recognizes
--versionand--version-path. So on a repo that has deliberately split the formats,classifyreportsDRIFT_UNEXPECTEDandwritesilently reintroduces the invalid version — putting the broken deploy back. Ship's own SKILL.md tells the agent to STOP onDRIFT_UNEXPECTED, which is correct, but there's then no supported way forward except hand-editing both files and bypassing the tool.Two things that would fix it:
--no-package-jsonflag (or aversion_sync_package_json: falseconfig key) sowrite/repairleavepackage.jsonalone.classifythat a deliberate 4-digit/3-digit split is a valid state, notDRIFT_UNEXPECTED.Happy to send a PR for (1) if that's the direction you'd want.
time-attack commentedon Jul 15, 2026
@16francej — recommend closing this issue as a duplicate of #1474. The strict-SemVer failure is one part of the broader release-identity problem, and a local exception would leave package, tag, changelog, and release behavior inconsistent. Preserve the reproduction and ensure #1474 covers package-version mapping or a no-mirror mode.
capy-ai commentedon Oct 3, 2026
/ship still keeps the 4-digit VERSION file, but it now writes the npm-valid 3-digit translation into package.json (probe on main:
gstack-version-bump write --version 0.1.1.0wrote VERSION 0.1.1.0 and package.json "0.1.1"), so npm and Prisma no longer see a 4-part version. Fixed in v1.67.0.0 (#2604).If you still see this on the latest gstack, please reopen with details.