Jon Skeet

I've just realized that this would be a breaking change after all - because users may already have a static constructor of their own. Will close this PR for now,...

Reopening with a *slightly* alternate design: - The static constructor is now in the reflection class. While this is *also* partial (so it could very-theoretically be a breaking change) I...

@JamesNK: Thanks for looking at this and for your thoughtful reply. Replying to your individual points: **Whether or not this is an issue worth addressing** This hasn't caused customer problems...

> > My reasoning for validating this as early as possible in code terms is to prompt users as early as possible in development lifecycle terms. > > The cost...

I'll discuss the "changes for generated code" vs "changes in other aspects of the public API" with the Protobuf team - but fundamentally that still would still leave us running...

Coming back to this, I discussed the separation of changes for generated code vs other aspects of the public API with the protobuf team, and the feedback was that it...

Removed the inactive tag as we do still want to do this. @JamesNK any further thoughts? Maybe we should have a meeting to discuss?

> In my preferred validation check the Protobuf library has validated that the generated code is supported with MinSupportedMajorVersion. It isn't "hope that it works". Acknowledged. There's still the slippery...

> Simple is good but it brings along its friend, inflexible. And inflexible + dependencies aren't a good combination. .NET Framework's simple but inflexible binding rules with strong named assemblies...

The policy at https://protobuf.dev/support/cross-version-runtime-guarantee/#major has now been updated to include this: > Starting with the 2025Q1 release, the protobuf project will adopt a rolling compatibility window for major versions. Code...