maint: add x86_64 suffix to macOS build

[vladdoster]

This is currently a convention for Windows systems. Additionally, it makes the release naming convention consistent.

[vladdoster]

Requesting for review

@charlespierce || @chriskrycho || @mikrostew || @vanstinator

[vladdoster]

Given the following commands:

M1:

ᐳ echo $OSTYPE $MACHTYPE $VENDOR $CPUTYPE $(uname -m -p -v)
darwin21.0 x86_64 apple arm64 Darwin Kernel Version 21.4.0: Mon Feb 21 20:35:58 PST 2022; root:xnu-8020.101.4~2/RELEASE_ARM64_T6000 arm64 arm

x86_64 (e.g., Intel and M1 via Rosetta):

ᐳ echo $OSTYPE $MACHTYPE $VENDOR $CPUTYPE $(uname -m -p -v)
darwin21.4.0 x86_64 apple x86_64 Darwin Kernel Version 21.4.0: Mon Feb 21 20:34:37 PST 2022; root:xnu-8020.101.4~2/RELEASE_X86_64 x86_64 i386

It just occurred to me that the following suffixes make more sense.

x86_64 and arm64, respectively

[vladdoster]

I realize aarch64 is an alias for arm64, and IRC was added in ARM v7? However, I don't know what command I could run to return aarch64, whereas arm64 is the value Darwin has chosen to use.

[vladdoster]

Here are a few examples of other popular packages.

1. https://github.com/cli/cli/releases
2. https://github.com/go-gitea/gitea/releases

[charlespierce]

Hi @vladdoster, thanks for the suggestion! While I absolutely understand the desire for consistency, the reason we didn't add the suffix when we added support for M1 devices is backwards compatibility of our installer script. Prior the release of Apple Silicon devices, we only had a single MacOS build, so there wasn't an architecture component. The install script needs to know which file to look for when fetching a given release, so we felt it was best to maintain the naming conventions in a non-breaking way.

We'd definitely be open to a holistic approach that updates the names while also maintaining a "legacy" install script, if you'd be up to something like that. It would be useful as well as we look towards creating a statically-linked binary (which will reduce the number of linux builds and require similar name-change logic). It may also be that we can roll the two together as a single change to the installer.