Thank you for the contribution, historically we considered this a feature as for general usage we want the LD flags set and for end users to use the prebuilt binaries and docker images, while developers have the local code and can run it easily.

Curious what others think but not strongly against this, I just don't think we want people reaching for Go Install as a supported installation method because of the unspecified LD flags etc.

Ok, I see.

As far as I understand the linker flags it's
(a) for optimizing binary size - which is not relevant in case of "go run" usage
(b) having version, commit, date as part of the compiled program - this would be missing in case of "go run" usage. Maybe I can change the defaults in root_command.go?

At least in my opinion it would be a benefit having the "go run" option additionally to Docker/binary artifacts.

version, commit, date

So mostly commit and version are significant because we have this as part of the API user agent string so if requests keep failing we can understand which version it is and fix it.

We don't mind for development, but for actual usage we want to know at least the commit.

This isn't a hard no though, I think the current usage patterns are entrenched enough that enabling this pathway won't necessarily be a problem but need to check with@toby a d others internally.

Just an idea: When doing a release using goreleaser, the defaults in root_command.go could be set to the current version/commit/date for the specific release.

This would maybe be it

chore: extract versioning logic into script and simplify ldflags- Moved version management to `script/update-version` for easier maintenance.- Removed complex ldflags from Dockerfile and `.goreleaser.yaml`.- Integrated version update step in GitHub Actions workflow.

version-update.patch