chore: re-vendor protobuf.lua from lua-protobuf v0.6.11 - #85
Merged
Merged
Conversation
Verbatim copy of the `protobuf.lua` asset from the lua-protobuf v0.6.11 release (sha256 5e19f05dda5453d7165a3c8584e1aa41a5ca4618245de15192fb84bd8af2a1e9, 74877 bytes). The diff is the `VERSION` line only, v0.6.10 to v0.6.11: #35 changed tools/gen_lua_proto_schema, its tests and CLAUDE.md, and nothing under src/, so the runtime is unchanged apart from the stamp. The file on main was byte-identical to the v0.6.10 asset, so no local change is dropped. A consumer's proto-schema check runs lua-protobuf at the tag its vendored runtime reports, so this is what brings #35's generator (options decoded by declared type, a failed generation exiting non-zero) to driver repos.
Contributor
There was a problem hiding this comment.
Verified at db89363:
template/vendor/protobuf.luaat head is byte-identical to the v0.6.11protobuf.luaasset (sha2565e19f05d…2a1e9, 74877 bytes), and the file on main222bb79is byte-identical to the v0.6.10 asset (bd970eb6…1ebd0). No local change is dropped.v0.6.10...v0.6.11is one commit,3ad17bb(#35), touchingCLAUDE.md,Makefile,test/gen_schema_controls.shandtools/gen_lua_proto_schema. Nothing undersrc/, so theVERSIONline is the only runtime difference. (The body leaves out theMakefile, which only changes a comment, so it does not affect that conclusion.)- No other
0.6.10reference remains in the template. - The downstream note holds: control4-esphome's
proto-schema.ymlreads the vendoredlocal VERSIONand checks out lua-protobuf at that tag, so its template-update PR has to regenerate in the same change. That repo's main is still at v0.6.10.
CI 7/7 green.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Verbatim copy of the
protobuf.luaasset from the lua-protobuf v0.6.11 release (sha2565e19f05d…2a1e9, 74877 bytes). The diff is theVERSIONline only: v0.6.10...v0.6.11 is finitelabs/lua-protobuf#35, which changed the schema generator, its tests and CLAUDE.md, and nothing undersrc/. The file on main was byte-identical to the v0.6.10 asset, so no local change is dropped.A consumer's proto-schema check runs lua-protobuf at the tag its vendored runtime reports, so this is what brings #35's generator to driver repos: options decoded by their declared type, and a failed generation exiting non-zero instead of leaving a stale schema.
Downstream: control4-esphome's template update must re-run
make gen-protoin the same PR, or its proto-schema check fails on the new runtime version. The regeneration changes itsboolmessage options from1/0totrue/false(69 lines); the driver reads onlyoptions.idandoptions.ifdef, which do not change.