Skip to content

Populate min_version BrushFamily proto field.#511

Open
copybara-service[bot] wants to merge 1 commit intomainfrom
test_872916698
Open

Populate min_version BrushFamily proto field.#511
copybara-service[bot] wants to merge 1 commit intomainfrom
test_872916698

Conversation

@copybara-service
Copy link

@copybara-service copybara-service bot commented Feb 20, 2026

Populate min_version BrushFamily proto field.

Introduces code to calculate the minimum required version of Ink for a BrushFamily (and each part of a BrushFamily). The code is used during serialization to compute the value to store in the min_version field. During deserialization, the min_version field is used to determine if a BrushFamily is compatible with the current version of Ink; if it isn't, decoding it is aborted.

All future features added to custom brushes must be associated with a version number in the proto, and that same number must associated with that feature in the appropriate part of CalculateMinimumRequiredVersion. There are two options when selecting a version for a new feature:

  • version::kMax + 1. This will create a new version level and cement the new feature as part of the custom brush API that the Ink team will support. If this option is chosen, kMax itself must be incremented as well.
  • version::kDevelopment. This value is a sentinel (represented under the hood with int32 max()) to hold features which aren't ready to be released yet. Brushes containing features associated with kDevelopment will fail to be deserialized under normal circumstances (an optional argument to DecodeBrush/BrushFamily() controls this). This is WAI, since kDevelopment > kMax. Features associated with kDevelopment are unstable, so Ink makes no guarantees they will be supported by future versions. Serializing them is risky, and deserializing them is especially risky. Brushes with the version kDevelopment may contain features no longer supported, or whose interfaces have changed. These features are available for the purposes of prototyping and research, and deserializing them is only provided as an option for the purpose of convenience. Deserializing a brush with a version of kDevelopment may lead to unexpected behavior.

To ensure the code in the web of CalculateMinimumRequiredVersion functions lines up with expectations, protobuf options are used to build consistency check tests. CalculateMinimumRequiredVersion serves as the enforcement of the expectations set in the protobuf itself. The tests are:

  • A fuzz test to generate valid brush families and serialize them. Then, it checks the value in min_version against all the options set for the fields, messages, and enum values, to ensure it is equal to the highest value set for the relevant options. This ensures CalculateMinimumRequiredVersion is consistent with the protobuf options.
  • A test to iterate over all the messages, fields, and enum values in brush_family.proto, starting at the top-level BrushFamily message, and verify that they all have a relevant field_min_version, message_min_version, or enum_value_min_version set, and that this value set is less than or equal to the maximum compatible version (version::kMax).
  • A test to verify that decoding a proto::Version out of the acceptable range (higher than version::kMax, lower than version::kMin) will fail.
  • A test to verify that decoding a proto::BrushFamily with no value set for its min_version field will not fail, to ensure older brushes are still able to be loaded.
  • Tests to verify that DecodeBrush() and DecodeBrushFamily() will accept brushes with the version kDevelopment if passed the appropriate argument.

A more direct implementation, using reflection to examine the descriptors of the protobuf directly during serialization, was considered, but ultimately rejected. It would have required both static and runtime reflection, and increased libink.so size by ~2%.

@copybara-service copybara-service bot force-pushed the test_872916698 branch 5 times, most recently from 0d1a2eb to 396c618 Compare February 25, 2026 21:28
@copybara-service copybara-service bot changed the title Introduces code to calculate the minimum required version of Ink for a BrushFamily (and each part of a BrushFamily). The code is used during serialization to compute the value to store in the min_version field. During deserialization, the min_version field is used to determine if a BrushFamily is compatible with the current version of Ink; if it isn't, decoding it is aborted. Populate min_version BrushFamily proto field. Feb 25, 2026
Introduces code to calculate the minimum required version of Ink for a BrushFamily (and each part of a BrushFamily). The code is used during serialization to compute the value to store in the `min_version` field. During deserialization, the `min_version` field is used to determine if a BrushFamily is compatible with the current version of Ink; if it isn't, decoding it is aborted.

All future features added to custom brushes must be associated with a version number in the proto, and that same number must associated with that feature in the appropriate part of `CalculateMinimumRequiredVersion`. There are two options when selecting a version for a new feature:
* `version::kMax + 1`. This will create a new version level and cement the new feature as part of the custom brush API that the Ink team will support. If this option is chosen, `kMax` itself must be incremented as well.
* `version::kDevelopment`. This value is a sentinel (represented under the hood with `int32 max()`) to hold features which aren't ready to be released yet. Brushes containing features associated with `kDevelopment` will fail to be deserialized under normal circumstances (an optional argument to `DecodeBrush/BrushFamily()` controls this). This is WAI, since `kDevelopment > kMax`. Features associated with `kDevelopment` are unstable, so Ink makes no guarantees they will be supported by future versions. Serializing them is risky, and deserializing them is especially risky. Brushes with the version `kDevelopment` may contain features no longer supported, or whose interfaces have changed. These features are available for the purposes of prototyping and research, and deserializing them is only provided as an option for the purpose of convenience. Deserializing a brush with a version of `kDevelopment` may lead to unexpected behavior.

To ensure the code in the web of `CalculateMinimumRequiredVersion` functions lines up with expectations, protobuf options are used to build consistency check tests. `CalculateMinimumRequiredVersion` serves as the enforcement of the expectations set in the protobuf itself. The tests are:
* A fuzz test to generate valid brush families and serialize them. Then, it checks the value in `min_version` against all the options set for the fields, messages, and enum values, to ensure it is equal to the highest value set for the relevant options. This ensures `CalculateMinimumRequiredVersion` is consistent with the protobuf options.
* A test to iterate over all the messages, fields, and enum values in `brush_family.proto`, starting at the top-level `BrushFamily` message, and verify that they all have a relevant `field_min_version`, `message_min_version`, or `enum_value_min_version` set, and that this value set is less than or equal to the maximum compatible version (`version::kMax`).
* A test to verify that decoding a `proto::Version` out of the acceptable range (higher than `version::kMax`, lower than `version::kMin`) will fail.
* A test to verify that decoding a `proto::BrushFamily` with no value set for its `min_version` field will ***not*** fail, to ensure older brushes are still able to be loaded.
* Tests to verify that `DecodeBrush()` and `DecodeBrushFamily()` will accept brushes with the version `kDevelopment` if passed the appropriate argument.

A more direct implementation, using reflection to examine the descriptors of the protobuf directly during serialization, was considered, but ultimately rejected. It would have required both static and runtime reflection, and increased `libink.so` size by ~2%.

PiperOrigin-RevId: 872916698
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant