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
{{ message }}
Repository navigation
Epic: Release, distribution, and self-install #453
How the tools reach a machine and say what they are: goreleaser, the LKG tag workflow, licensing and SPDX
headers, self install / self upgrade, shell completions and man pages.
Landed: version stamping — --version and the version command in the docker shape, with the release
path guarded so an unstamped binary cannot ship. Self-install now runs as a real-binary scenario on all
three platforms, which is what caught Windows installs landing without an .exe suffix.
The model. Every CI run builds its binaries once, stamped with that build's version, into a well-known location.
Anyone can pick up the build for any CI run. Release packaging takes the binaries it needs from that same location and
never compiles. What ships is then the exact bytes CI tested, and any build is installable, not only tagged ones.
goreleaser against that model. Open-source goreleaser always builds for itself: builds: compiles. Importing
prebuilt binaries, builder: prebuilt with prebuilt.path, is a Pro feature: "exclusively available with GoReleaser
Pro" (Import pre-built binaries). Its stated uses
match the model: building on other machines, using an existing build tool such as a Makefile, and building in parallel.
It recommends one config to build and a second to import and release.
So the choice is:
GoReleaser Pro consuming the drop, which also brings nfpms, brews and winget over prebuilt binaries.
Open-source goreleaser, which rebuilds at release and breaks build once.
No goreleaser.make dist splits into a build that writes the drop and packaging that only archives and checksums
it.
Unaffected by the choice.#903 fixes what an archive holds: every product in $(PRODUCTS), and star's extensions at share/star/extensions, the layout .goreleaser.yaml already describes. It also fixes what the installers take from
an archive. Both hold whichever packager this issue picks.
Activity
doc(release): write down which release path is real, and stage star i…
David-Noble-at-work commentedon Sep 22, 2026
The owner's model: build once into a drop, and package from it (2026-09-22)
Discussed during #903, lane 7 of NobleFactor/noblefactor-ops#217, and recorded here because the goreleaser decision is
this issue's.
The model. Every CI run builds its binaries once, stamped with that build's version, into a well-known location.
Anyone can pick up the build for any CI run. Release packaging takes the binaries it needs from that same location and
never compiles. What ships is then the exact bytes CI tested, and any build is installable, not only tagged ones.
goreleaser against that model. Open-source goreleaser always builds for itself:
builds:compiles. Importingprebuilt binaries,
builder: prebuiltwithprebuilt.path, is a Pro feature: "exclusively available with GoReleaserPro" (Import pre-built binaries). Its stated uses
match the model: building on other machines, using an existing build tool such as a Makefile, and building in parallel.
It recommends one config to build and a second to import and release.
So the choice is:
nfpms,brewsandwingetover prebuilt binaries.make distsplits into a build that writes the drop and packaging that only archives and checksumsit.
Unaffected by the choice. #903 fixes what an archive holds: every product in
$(PRODUCTS), and star's extensions atshare/star/extensions, the layout.goreleaser.yamlalready describes. It also fixes what the installers take froman archive. Both hold whichever packager this issue picks.