Protocol Buffers Schema Evolution - Baseline
The baseline proto3 Customer message for field-number and wire-compatibility testing. Reference wire contract: field 1 is string id and field 2 is string name.
syntax = "proto3";
package novus.p6.customer.v1;
message Customer {
string id = 1;
string name = 2;
}
Specifications
- Schema Family
- Protocol Buffers
- Version Role
- baseline
- Expected Compatibility
- reference
- Syntax
- proto3
- Messages
- 1
- Fields
- 3
Testing contract
Reference control- Scenario
- Compare the baseline Protocol Buffers contract against the baseline member using a compatibility checker.
- Expected result
- Reference wire contract: field 1 is string id and field 2 is string name.
What is a .proto file?
Proto files define Protocol Buffers schemas, Google's language-neutral interface definition language for serializing structured data. They declare typed messages, fields, and services that a compiler turns into efficient binary serialization code in many languages. They underpin gRPC and high-performance data interchange.
How to use this file
Use an example proto file to test schema parsers, code generation across languages, and gRPC service or message-definition tooling.
How to use this file for testing
“Protocol Buffers Schema Evolution - Baseline” is a deterministic Novus Examples fixture for Schema / OpenAPI testing, Schema validation, API testing, Conversion testing. Valid and intentionally invalid OpenAPI/JSON Schema documents plus request/response examples for schema validators and API tooling.
Documented properties for this file: 1 messages · 3 fields. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such — expect parsers to fail loudly rather than silently accept them.
Data fixtures document their exact quirks — delimiters, encodings, null handling, schema, and row counts — in the spec table. Point your parser or importer at the file and assert it handles the documented edge cases; clean and deliberately-messy siblings make before/after diffs straightforward.
Valid and intentionally invalid siblings are labelled in title and description. Assert parsers accept the valid twin and fail loudly on the invalid one; for time series, check DST gaps and duplicate keys against the spec table.
Related files
- jsonAvro Schema Evolution - Backward-CompatibleThe compatible Avro record schema for reader/writer compatibility tests. Backward compatible for old records: nullable email is added with a null default.
- jsonAvro Schema Evolution - BaselineThe baseline Avro record schema for reader/writer compatibility tests. Reference writer schema: id and name are strings.
- jsonAvro Schema Evolution - BreakingThe breaking Avro record schema for reader/writer compatibility tests. Breaking relative to baseline: id changes to long and tenantId has no default.
- jsonJSON Schema Schema Evolution - Backward-CompatibleThe compatible member of a JSON Schema 2020-12 customer contract. Backward compatible: existing instances remain valid because email is optional.
- jsonJSON Schema Schema Evolution - BaselineThe baseline member of a JSON Schema 2020-12 customer contract. Reference contract: id and name are required strings.
- jsonJSON Schema Schema Evolution - BreakingThe breaking member of a JSON Schema 2020-12 customer contract. Breaking relative to baseline: id changes from string to integer and tenantId becomes required.
Generated by generation/p6_core.py. Free for any use, no attribution required — license.