Pablo Baeyens
Pablo Baeyens
Was this fixed by #733?
> Why are branches and forks not a valid place for this type of code? This is not a viable solution if you want to use opentelemetry-go types as part...
I would go as far as saying as a user of opentelemetry-go, I would rather have to deal with (properly namespaced) build tags than have to use a fork.
I think this comment may be relevant in this discussion: https://github.com/open-telemetry/opentelemetry-collector/issues/4832#issuecomment-1039394229 It summarizes ways in which grpc-go's policy has caused harm to the Go ecosystem
> > You are forced to use the fork indefinitely if you don't want to make a breaking change > > @mx-psi, I think only a long-living branch with releases...
> > You are forced to use the fork indefinitely if you don't want to make a breaking change > > @mx-psi, I think only a long-living branch with releases...
> it seems that from Go 1.21 and onward, there needs to be a sub-version specified in go.mod files. https://github.com/golang/go/issues/62278 There is no requirement for this, as you can see,...
From @douglascamata on Slack, discussed on the 2025-01-22 SIG meeting: > here's a link from the goreleaser docs that shows that they have some support for it in the release...
I filed https://github.com/orgs/goreleaser/discussions/5875 to seek feedback from the `goreleaser` maintainers