sungwy opened a new issue, #102:
URL: https://github.com/apache/terraform-provider-iceberg/issues/102
## Summary
The convenience binaries attached to a final release embed the **release
candidate**
version in their Go build info, because `dev/release/release.sh` reuses the
RC
binaries bit-for-bit rather than rebuilding.
Inspecting the artifact from the v0.1.0-rc2 prerelease:
```
$ go version -m terraform-provider-iceberg_v0.1.0
mod github.com/apache/terraform-provider-iceberg v0.1.0-rc2
build vcs.revision=186d4f48b9e98386b044e1367d6fdf8d47a3ff8d
build vcs.modified=false
```
The file is named `terraform-provider-iceberg_0.1.0_linux_amd64.zip` and the
binary
inside is `terraform-provider-iceberg_v0.1.0`, but the embedded module
version reads
`v0.1.0-rc2`. Per `docs/releasing.md`, `release.sh` attaches the
already-signed RC
binaries to the final release and "nothing is rebuilt," so this is what
ships.
The mismatch arises because `tf-release.yml` forces GoReleaser's version for
*filenames* via `GORELEASER_CURRENT_TAG: v${VERSION}`, while Go derives the
build-info
module version from the VCS tag actually being built (`v0.1.0-rc2`).
## Impact
Low, and user-invisible today. Terraform resolves the provider version from
the
registry metadata and filename, not from Go build info. The provider itself
never
surfaces a version string — `Metadata()` sets only `resp.TypeName` and never
`resp.Version`, and there is no User-Agent or `debug.ReadBuildInfo()` call
anywhere
in `internal/` or `main.go`.
So the effect is limited to provenance/traceability: anyone running `go
version -m`
on a released binary, or reading build info in an SBOM or supply-chain
scanner, sees
`v0.1.0-rc2` for what is published as `0.1.0`.
## Why it may be worth leaving alone
Reusing the RC binaries is deliberate and valuable: what users install is
bit-for-bit
what the PMC voted on. Rebuilding at the final tag to correct the version
string would
trade that guarantee away for a cosmetic fix. That is very likely a bad
trade.
## Options
1. **Accept and document.** Add a note to `docs/releasing.md` explaining
that release
binaries carry the RC version in build info by design, so it is not
mistaken for a
packaging error later.
2. **Stamp the version explicitly** via `-ldflags -X` into a variable the
provider owns,
set from `GORELEASER_CURRENT_TAG` so it reads `0.1.0` in both RC and
final builds.
The Go module version in build info would still say `-rc2`, so this only
helps if
the provider starts surfacing its own version.
Option 1 is probably right unless the provider grows a real version string.
Filed separately from the `LICENSE-binary` drift issue — unrelated cause,
unrelated fix.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
