protobuf

18322 Commits

201 Branches

346 Tags

254 MiB

Tag: Branch: Tree: cdd3cf7ed4

Commit Graph

Author SHA1 Message Date

Author	SHA1	Message	Date
Sandy Zhang	df8a11e266	Binary compatibility shims for GeneratedMessageV3, SingleFieldBuilderV3, RepeatedFieldBuilderV3, and their nested classes to restore binary compatibility with <=v3.x.x generated code built against v3.x.x prior to v4.26.0 breaking release. 3.x.x descriptor.proto generated code is not supported with 4.x.x runtime, since this results in an ODR violation with the descriptor.proto built into the 4.x.x runtime. This is expected to result in undefined behavior / failures. Tested against //java/core:v25_generated_message_test_jar (binary compatibility) and //java/core:v25_generated_message_test_srcjar (source compatibility) PiperOrigin-RevId: 666329342	3 months ago
jchadwick-buf	db48abbef4	Add breaking change detection for well-known types (#17513 ) Adds new tests in `//compatibility` for detecting undesired breaking changes in the schema of the well-known types and `descriptor.proto` files, using the Buf breaking change detector, via [`rules_buf`](https://github.com/bufbuild/rules_buf/). In order to keep things light-touch as far as maintenance goes, I have chosen to keep the integration as small and simple as possible. Some notes: - Breaking change behavior can be granularly controlled via [`buf.yaml`](https://buf.build/docs/configuration/v1/buf-yaml#breaking). - Bazel sandboxes us away from meaningful VCS information, so in order to pick a target to check for breaking changes against, a new variable is added to `protobuf_versions.bzl` that needs to be updated with changes in the release version. - Breaking change detection is performed on a file-level, not a package-level, so migrating types across WKT files would constitute a breaking change. If this is not desired the behavior can be made to work on a package-level, though we need to do some more work as `buf_breaking_test` currently only accepts a single file descriptor set target for the `against` attribute. Closes #17513 COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/17513 from jchadwick-buf:buf-breaking `cd46bb2c1e` PiperOrigin-RevId: 658624708	4 months ago
Protobuf Team Bot	507ba36e29	Support building //java with bzlmod Create WORKSPACE.bzlmod. Before building with Bzlmod resulted in use of full WORKSPACE. Some repos are still there, but the file should eventually be empty. Add dep to rules_kotlin 1.9.0. This was the first version available on BCR. It pushed upgrade of rules_jvm_external to 6.0 and rules_java to 6.5.2 (keep 6.0.0 on Bazel 6.3.0). Add missing maven and other deps to MODULE.bazel CI changes: Disable Bazel 6.4.0 with bzlmod. rules_jvm_external 6.0 use use_repo_rule, which is not supported by Bazel 6. Add C++ build "Bazel7 with Bzlmod" enabled. Add Java builds with "Bazel 7 with/without Bzlmod". Fixes: https://github.com/protocolbuffers/protobuf/issues/17176 PiperOrigin-RevId: 652773197	5 months ago

Sandy Zhang

df8a11e266

Binary compatibility shims for GeneratedMessageV3, SingleFieldBuilderV3, RepeatedFieldBuilderV3, and their nested classes to restore binary compatibility with <=v3.x.x generated code built against v3.x.x prior to v4.26.0 breaking release.

3.x.x descriptor.proto generated code is *not* supported with 4.x.x runtime, since this results in an ODR violation with the descriptor.proto built into the 4.x.x runtime. This is expected to result in undefined behavior / failures.

Tested against //java/core:v25_generated_message_test_jar (binary compatibility) and //java/core:v25_generated_message_test_srcjar (source compatibility)

PiperOrigin-RevId: 666329342

3 months ago

jchadwick-buf

db48abbef4

Add breaking change detection for well-known types (#17513 )

Adds new tests in `//compatibility` for detecting undesired breaking changes in the schema of the well-known types and `descriptor.proto` files, using the Buf breaking change detector, via [`rules_buf`](https://github.com/bufbuild/rules_buf/).

In order to keep things light-touch as far as maintenance goes, I have chosen to keep the integration as small and simple as possible. Some notes:

- Breaking change behavior can be granularly controlled via [`buf.yaml`](https://buf.build/docs/configuration/v1/buf-yaml#breaking).

- Bazel sandboxes us away from meaningful VCS information, so in order to pick a target to check for breaking changes against, a new variable is added to `protobuf_versions.bzl` that needs to be updated with changes in the release version.

- Breaking change detection is performed on a file-level, not a package-level, so migrating types across WKT files would constitute a breaking change. If this is not desired the behavior can be made to work on a package-level, though we need to do some more work as `buf_breaking_test` currently only accepts a single file descriptor set target for the `against` attribute.

Closes #17513

COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/17513 from jchadwick-buf:buf-breaking cd46bb2c1e
PiperOrigin-RevId: 658624708

4 months ago

Protobuf Team Bot

507ba36e29

Support building //java with bzlmod

Create WORKSPACE.bzlmod. Before building with Bzlmod resulted in use of full WORKSPACE.
Some repos are still there, but the file should eventually be empty.

Add dep to rules_kotlin 1.9.0. This was the first version available on BCR. It pushed upgrade of
rules_jvm_external to 6.0 and rules_java to 6.5.2 (keep 6.0.0 on Bazel 6.3.0).

Add missing maven and other deps to MODULE.bazel

CI changes:
Disable Bazel 6.4.0 with bzlmod. rules_jvm_external 6.0 use use_repo_rule, which is not supported by Bazel 6.
Add C++ build "Bazel7 with Bzlmod" enabled.
Add Java builds with "Bazel 7 with/without Bzlmod".

Fixes: https://github.com/protocolbuffers/protobuf/issues/17176
PiperOrigin-RevId: 652773197

5 months ago

3 Commits (cdd3cf7ed4a34d9b01065ffef41988c1aefc663c)