Skip to content

Versioning Scheme #430

Closed
Closed

Description

@anhldbk

Hi @garrytan ,

Thank you for this outstanding framework.

While using gstack for a green-field project, I've got an issue while running the generated code:

$ npx run-the-command
npm error Invalid Version: 0.1.0.0
npm error A complete log of this run can be found in: ...

Looks like npm only support SemVer. I replaced all "0.1.0.0" with "0.1.0" and the command works.

My question is: why do we use a new version scheme (x.y.z.t) in this project? For example:

Activity

  1. travisbotello commented on Jul 14, 2026

    @travisbotello

    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.json version 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:

    if (existsSync(join(cwd, "package.json"))) {
      try {
        writePkgVersion(cwd, version!);
      }

    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:

    1. A --no-package-json flag (or a version_sync_package_json: false config key) so write/repair leave package.json alone.
    2. 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.

  2. time-attack commented on Jul 15, 2026

    @time-attack
    Contributor

    @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.

  3. capy-ai commented on Oct 3, 2026

    @capy-ai
    Contributor

    /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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions