Breaking change

[CodeLieutenant]

After the release of v1.0.3 this library is no longer backwards compatible with the old proto.Message interface

V1 Message Interface

type MessageV1 interface {
	Reset()
	String() [string](https://pkg.go.dev/builtin#string)
	ProtoMessage()
}

After the import of new protobuf package from google.golang.org/protobuf/proto proto.Message is https://pkg.go.dev/google.golang.org/protobuf@v1.28.1/reflect/protoreflect#ProtoMessage

type ProtoMessage interface{ 
   ProtoReflect() Message 
}

This currently breaks https://github.com/prometheus/common/blob/main/expfmt/decode.go

go/pkg/mod/github.com/prometheus/common@v0.37.0/expfmt/decode.go:89:38: cannot use v (variable of type *io_prometheus_client.MetricFamily) as type protoreflect.ProtoMessage in argument to pbutil.ReadDelimited:
        *io_prometheus_client.MetricFamily does not implement protoreflect.ProtoMessage (missing ProtoReflect method)

go/pkg/mod/github.com/prometheus/common@v0.37.0/expfmt/encode.go:120:40: cannot use v (variable of type *io_prometheus_client.MetricFamily) as type protoreflect.ProtoMessage in argument to pbutil.WriteDelimited:
        *io_prometheus_client.MetricFamily does not implement protoreflect.ProtoMessage (missing ProtoReflect method)

Could you please remove this release and tag it with v2.0.0 or something?

[nicolaasuni-vonage]

After upgrading to github.com/matttproud/golang_protobuf_extensions v1.0.3 I get the following errors:

# github.com/prometheus/common/expfmt
../../../../pkg/mod/github.com/prometheus/common@v0.37.0/expfmt/decode.go:89:38: cannot use v (variable of type *io_prometheus_client.MetricFamily) as type protoreflect.ProtoMessage in argument to pbutil.ReadDelimited:
	*io_prometheus_client.MetricFamily does not implement protoreflect.ProtoMessage (missing ProtoReflect method)
../../../../pkg/mod/github.com/prometheus/common@v0.37.0/expfmt/encode.go:120:40: cannot use v (variable of type *io_prometheus_client.MetricFamily) as type protoreflect.ProtoMessage in argument to pbutil.WriteDelimited:
	*io_prometheus_client.MetricFamily does not implement protoreflect.ProtoMessage (missing ProtoReflect method)

The linter golangci-linter fails with:

ERRO Running error: 1 error occurred:
	* can't run linter goanalysis_metalinter: inspect: failed to load package prometheus: could not load export data: no export data for "github.com/****/****/prometheus"

[matttproud]

Pin to v1.0.2 in the interim. I will move this to another major version within a day or two. Nicola Asuni (Vonage) ***@***.***> schrieb am Di. 25. Okt. 2022 um 11:58:

…

After upgrading to github.com/matttproud/golang_protobuf_extensions v1.0.3 I get the following errors: # github.com/prometheus/common/expfmt ..***@***.***/expfmt/decode.go:89:38: cannot use v (variable of type *io_prometheus_client.MetricFamily) as type protoreflect.ProtoMessage in argument to pbutil.ReadDelimited: *io_prometheus_client.MetricFamily does not implement protoreflect.ProtoMessage (missing ProtoReflect method) ..***@***.***/expfmt/encode.go:120:40: cannot use v (variable of type *io_prometheus_client.MetricFamily) as type protoreflect.ProtoMessage in argument to pbutil.WriteDelimited: *io_prometheus_client.MetricFamily does not implement protoreflect.ProtoMessage (missing ProtoReflect method) The linter golangci-linter fails with: ERRO Running error: 1 error occurred: * can't run linter goanalysis_metalinter: inspect: failed to load package prometheus: could not load export data: no export data for "github.com/****/****/prometheus" — Reply to this email directly, view it on GitHub <#19 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAALIRP56W7JV47VYRSUCQTWE6VKRANCNFSM6AAAAAARNYGOXM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[nomad-software]

Hi @matttproud could this be worked on as a priority please this is a big breaking change and just took me ages to find the cause and it affects many of our services. Thanks.

[matttproud]

As I said, yes, I will address soon. I am currently about 200km from my laptop, so you will need to have some patience. Please either pin to v1.0.2 or upgrade your Protocol Buffer version and message assets. Gary Willoughby ***@***.***> schrieb am Di. 25. Okt. 2022 um 12:29:

…

Hi @matttproud <https://github.com/matttproud> could this be worked on as a priority please this is a big breaking change and just took me ages to find the cause. Thanks. — Reply to this email directly, view it on GitHub <#19 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAALIRK3T6AANWLGDSOEH53WE6ZCJANCNFSM6AAAAAARNYGOXM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[CodeLieutenant]

Thank you for your time, hope it will be fixed soon.

[nomad-software]

Please either pin to v1.0.2 or upgrade your Protocol Buffer version and message assets.

The issue in my case is that this library is a transitive dependency of Prometheus which we use for all gRPC services.

I can pin it in my go.mod and it compiles fine, which is good. I guess a lot more people are going to have the same issue.

[CodeLieutenant]

Please either pin to v1.0.2 or upgrade your Protocol Buffer version and message assets.

The issue in my case is that this library is a transitive dependency of Prometheus.

I can pin it in my go.mod and it compiles fine, which is good. I guess a lot more people are going to have the same issue.

As I can see, this library is used in Prometheus common library and their GRPC models are not generated with new grpc version aka google.golang.org/protobuf/proto. Most likely as this will be breaking change for them and they don't want that.
Haven't seen this library used anywhere else except in Prometheus lib

[matttproud]

My main mistake was assuming that the generated Protocol Buffer message assets were forward-compatible (I recall hearing that they were supposed to be), so clearly this is not a patch revision. My apologies. If you can, work with partners to depend to v1.0.2 in the interim. You will get a fix for this when I am back at a computer. Dusan Malusev ***@***.***> schrieb am Di. 25. Okt. 2022 um 13:14:

…

Please either pin to v1.0.2 or upgrade your Protocol Buffer version and message assets. The issue in my case is that this library is a transitive dependency of Prometheus <https://github.com/prometheus/client_golang>. I can pin it in my go.mod and it compiles fine, which is good. I guess a lot more people are going to have the same issue. As I can see, this library is used in Prometheus common library and their GRPC models are not generated with new grpc version aka google.golang.org/protobuf/proto. Most likely as this will be breaking change for them and they don't want that. Haven't seen this library used anywhere else except in Prometheus lib — Reply to this email directly, view it on GitHub <#19 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAALIROJWMXZFOHJAOKR7ALWE66I5ANCNFSM6AAAAAARNYGOXM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[matttproud]

Thanks for bearing with me on this. I apologize for any inconvenience this caused. I was on the other side of Alps from my computer by the time the first defect report arose, which was why I couldn't immediately rectify this.

I have pushed a new tag v1.0.4, which is pinned to the v1.0.2 code. For now, the behavior of v1.0.4 and similar now lives in a legacy v1 branch. I expect that branch to go dormant long-term with a subsequent update that provides deprecation notices on the old APIs advising users to migrate to a new major version 2.

Going forward, the master branch will take the code of v1.0.3 and track what is today's current Protocol Buffer implementation and generated code API. This will become major version 2. Users should adapt to this where possible, though there is no need to worry that v1 will go away. Migrating to version 2 will require updating both the version of the Protocol Buffer library you use as well as any generated Protocol Buffer message file assets. For small and medium projects, this should be a simple affair. I will cut a version 2 release soon hereafter.

My instinct told me before cutting v1.0.3 I should have made a new major version instead, but I was not 100% certain due to these reasons. And then there is some extra ceremony involved with creating new module major versions.