pantry install zig-bump fails: package ships source only, source doesn't build on Zig 0.17-dev, release workflow attaches no binaries

[glennmichael123]

Summary

pantry install zig-bump@0.1.1 followed by pantry release patch --yes (the
intended downstream flow) fails with error: \bump` binary not found`. Three
distinct issues compound to make this unusable end-to-end:

1. The pantry-registry tarball for zig-bump@0.1.1 ships source files only —
   no compiled binary, no build.zig, no install/post-install hook. Nothing in
   the install puts a bump binary on PATH or in pantry/.bin/.
2. Even if a downstream user tries to build from the installed source (or from
   this repo at v0.1.3), the source does not compile on Zig 0.17-dev
   because of a half-applied std.ArrayList API migration.
3. The GitHub release workflow does not build or attach any binary assets, so
   there is also no prebuilt binary that pantry (or anyone) could fetch as a
   fallback.

Reproduction

In any project with pantry installed:

$ pantry install zig-bump
> Installing 1 package...
+ zig-bump@0.1.1
1 package installed [6213ms]

$ pantry release patch --yes
error: `bump` binary not found.

Install it with:
  pantry install zig-bump

pantry release is a built-in subcommand (pantry 0.9.35) that shells out to
an external bump binary. It cannot find one because pantry install zig-bump
did not install one.

Detail

1. Registry tarball is incomplete and noisy

After pantry install zig-bump, ./pantry/zig-bump/ contains:

bump.zig  cli.zig  config.zig  files.zig  git.zig  lib.zig  main.zig
semver.zig  test_version.zig  lib.zig  settings.local.json
workflows/{ci.yml,release.yml}
._bump.zig  ._cli.zig  ._config.zig  ...  (macOS AppleDouble resource forks)

Notably absent: build.zig, build.zig.zon, package.json, README.md,
LICENSE. Present but unexpected: a settings.local.json containing absolute
paths to the original author's machine
(/Users/chrisbreuer/Code/zig-bump/, /Users/chrisbreuer/Code/bumpx/) and a
full set of macOS ._* resource-fork files (indicates the tarball was created
with default macOS tar rather than tar --no-mac-metadata / COPYFILE_DISABLE=1).

Pantry's .bin/ directory in the project (./pantry/.bin/) is empty after install.

2. Source does not build on Zig 0.17-dev

zig build -Doptimize=ReleaseFast against this repo at v0.1.3 on
zig 0.17.0-dev.56+a8226cd53:

src/main.zig:282:38: error: missing struct field: items
    var commits = std.ArrayList([]u8){};
                  ~~~~~~~~~~~~~~~~~~~^~
src/main.zig:282:38: note: missing struct field: capacity

The codebase is in a partially-migrated state: src/main.zig lines 282, 414,
439, 465 use the new Zig 0.17 std.ArrayList(T){} empty-init form, while
src/git.zig, src/files.zig, src/cli.zig, src/bump.zig still use the
pre-0.17 std.ArrayList(T).init(allocator) form. So the source compiles cleanly
on no Zig version — pre-0.17 chokes on the empty-init sites; 0.17+ chokes
on the .init(allocator) sites.

build.zig.zon declares .minimum_zig_version = \"0.15.0\", which compounds the
issue: any Zig from 0.15 through 0.17-dev satisfies the declared minimum but
none can actually build the project.

3. Release workflow attaches no binary assets

.github/workflows/release.yml:

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Create Release
        uses: stacksjs/action-releaser@v1.2.9
        env:
          GITHUB_TOKEN: \${{ secrets.GITHUB_TOKEN }}
      - name: Publish to Pantry
        uses: home-lang/pantry/packages/action@main
        with:
          publish: zig
          install: 'false'

There is no zig build step and no upload-assets step. Consequently the
GitHub releases for v0.1.1 / v0.1.2 / v0.1.3 have an empty assets array, and
the "Publish to Pantry" step has no compiled artifact to upload — explaining
why pantry's registry tarball is source-only.

Suggested fixes

1. Make the source build on a supported Zig range. Pick one ArrayList API
   and use it consistently. If targeting Zig 0.17+, migrate all
   .init(allocator) call sites to the new empty-init / appendBounded-style
   API. If supporting both 0.15 and 0.17, gate with a comptime check on
   builtin.zig_version. Update .minimum_zig_version in build.zig.zon
   to match what actually builds.
2. Build and attach binaries in release.yml. Add a matrix
   (macos-latest arm64, macos x86_64, ubuntu-latest x86_64 + aarch64,
   windows-latest x86_64), run zig build -Doptimize=ReleaseFast -Dtarget=<triple> for each, and attach the resulting zig-out/bin/bump
   (renamed per target) as release assets.
3. Make the pantry publish include the binary. Whether that means the
   home-lang/pantry/packages/action reads from the GitHub release assets,
   or the workflow uploads the compiled binary as part of the publish payload,
   the resulting pantry install zig-bump should leave a working bump
   binary on the install path. Also fix the tarball hygiene
   (COPYFILE_DISABLE=1 / tar --no-mac-metadata, drop
   settings.local.json from the published files list).

Happy to PR (1) and (2). (3) likely needs coordination with whoever maintains
home-lang/pantry/packages/action.

Environment

• macOS (Darwin 25.3.0, arm64)
• pantry 0.9.35 (d8622c77a)
• zig 0.17.0-dev.56+a8226cd53

[glennmichael123]

Status update on v0.1.4 (thanks for the quick turnaround):

Fixed

• (2) GitHub release now attaches binaries for aarch64-macos, x86_64-macos, aarch64-linux-musl, x86_64-linux-musl, x86_64-windows-gnu, each with a .sha256 sidecar. Verified the aarch64-macos binary on darwin 25.3.0 / zig 0.17.0-dev.56+a8226cd53 — bump --version reports zig-bump v0.1.4, and it reads/updates build.zig.zon correctly.
• (1) Implicitly fixed: a binary was built and shipped, so the source must compile on some supported Zig.

Still broken

• (3) The pantry registry has not re-published. pantry install zig-bump and pantry install zig-bump@0.1.4 both still resolve to the old zig-bump@0.1.1 source-only tarball — pantry/.bin/ is empty after install, so pantry release patch --yes continues to fail with error: \bump` binary not found.Confirmed end-to-end that dropping the v0.1.4 binary intopantry/.bin/bumpmanually makespantry release` work, so this is purely a registry-publish issue.

Is the pantry registry republish something you can trigger from this repo (re-running the home-lang/pantry/packages/action@main step on v0.1.4 with the built binary as input), or does it need a separate ping to the pantry maintainers? Happy to file a follow-up issue against home-lang/pantry if that's the right venue.

[glennmichael123]

Correction to my previous comment — I was wrong about the registry republish.

The v0.1.4 publish-pantry job did succeed and published to the Zig namespace at registry.pantry.dev/zig/packages/zig_bump/0.1.4/tarball (HTTP 200, properly structured tarball with build.zig, build.zig.zon, src/). That's the right namespace for a Zig package and there is nothing left to fix on the publish side.

What I was previously hitting was the npm-side registry. pantry install zig-bump resolves against the npm namespace, which still serves the old zig-bump@0.1.1 source-only snapshot — but that namespace was never going to be the path for a Zig-built binary, so its state is irrelevant to a working downstream flow.

The actual remaining gap is more fundamental and probably out of scope for this repo: pantry release expects a bump binary on PATH / in pantry/.bin/, but pantry has no flow that installs a binary from either the Zig-namespace tarball (which is source, for zig fetch --save) or from this repo's GitHub release assets (which are the binaries). A downstream project that wants pantry release to work today still has to fetch the binary themselves — e.g., a small bootstrap script that downloads the matching bump-v0.1.4-<target>.tar.gz from the release assets and drops it into pantry/.bin/bump.

If there's a way to make pantry's installer recognize "this Zig-namespace package also publishes binaries — fetch the right one and put it in .bin/," that'd close the loop, but that's a feature request against home-lang/pantry or home-lang/pantry/packages/action, not this repo. From zig-utils/zig-bump's side I think the v0.1.4 release is complete.

Feel free to close this issue once you're satisfied — fixes (1) and (2) shipped, and (3) is misframed; sorry for the noise.