Skip to content

Use plain binary name inside release archives #96

Description

@alexrinass

Release archives currently contain binaries with version and platform baked into the filename (e.g. git-flow-v1.0.0-windows-amd64.exe). This forces users to rename the binary after extraction on every platform before it can be used as a Git subcommand.

The standard convention for CLI tools is to use the plain binary name inside the archive, with version/platform info only in the archive filename.

Current behavior

git-flow-next-v1.0.0-windows-amd64.zip
  └── git-flow-v1.0.0-windows-amd64.exe   # user must rename to git-flow.exe

git-flow-next-v1.0.0-darwin-arm64.tar.gz
  └── git-flow-v1.0.0-darwin-arm64         # user must rename to git-flow

Expected behavior

git-flow-next-v1.0.0-windows-amd64.zip
  └── git-flow.exe                         # works immediately

git-flow-next-v1.0.0-darwin-arm64.tar.gz
  └── git-flow                             # works immediately

Prior art

Every major Go CLI tool follows this convention:

Tool Archive name Binary inside
gh (GitHub CLI) gh_2.89.0_macOS_arm64.zip gh
ripgrep ripgrep-15.1.0-aarch64-apple-darwin.tar.gz rg
fzf fzf-0.71.0-darwin_arm64.tar.gz fzf
lazygit lazygit_0.60.0_darwin_arm64.tar.gz lazygit

This is also the GoReleaser default behavior.

Scope

  • Update scripts/build.sh to build binaries with the plain name (git-flow / git-flow.exe)
  • Archive filenames keep version/platform info (no change)
  • Simplify manual installation docs (rename step becomes unnecessary)

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions