Hello! I'm looking to reserve an option for a project I'm calling proto-telemetry. It will create open-telemetry compatible functions that add attributes to a span. Once this is accepted I'll update the project to use the reserved option number.
Thanks so much!
Closes#12758
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12758 from clly:proto-telemetry a8b38762d7
PiperOrigin-RevId: 532305028
```
* (M) docs/options.md
- Add two addition field options that are used as markers for
specific YANG types in generated protobufs.
```
This adds two additional unique `FieldOptions` field numbers for annotat YANG leaf-lists, and leaf-lists of unions that need specific handling in field option code. Definitions for these fields are in github.com/openconfig/ygygot, particularly https://github.com/openconfig/ygot/blob/master/proto/yext/yext.proto.
Closes#11518
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/11518 from robshakir:main ea73e697e7
PiperOrigin-RevId: 502245756
We are requesting a range of numbers instead of just one since we have some plans for a variety of orthogonal kinds of custom options. For example:
1. Injecting extra metadata into FileDescriptorProtos via custom options. (These options are inserted by the Buf tool when building proto sources, to encode additional metadata about the unit of files compiled.)
2. Configuration options for protoc plugins, that generate extra metadata into sources. (These options may be used by users when writing proto sources.)
The suggested approach of reserving just one number and making it a message that contains *all* options is unattractive since users of one category of options is unlikely to want to import types related to another category.
FWIW, there are several other rows above that have also chosen to reserve ranges of 5 or 10 numbers.
Closes#11110
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/11110 from jhump:jh/custom-options-for-buf-and-connect 68ef5ff1da
PiperOrigin-RevId: 492211135
LazyField explicitly registers `ArenaDtor` for destructing the lazy Cord contents which is particularly heavily used in extension sets. This is inefficient as it requires an indirect thunk call into the lazy field instance which then itself calls the Cord destructor. We can directly register the Cord for destruction which results in half the cleanup space (Tagged cleanup), and a direct call into the Cord destructor.
PiperOrigin-RevId: 491379222
* doc: Add document that describes protobuf_generate
How to use it.
How it works. (basic and with gRPC)
Reference documentation.
* doc: Address several typos and wording issues in cmake_protobuf_generate.md
* Fixing typos
* Revert new files that were deleted by sync script
* Fix CMake breakages
* bump upb version
* Sync from Piper @468772608
PROTOBUF_SYNC_PIPER
* Adding abseil to include path for python C++ extension
* Adding abseil linkage for python C++ extension
* Fixing linkage order
* Bazelfying conformance tests
Adding infrastructure to "Bazelify" languages other than Java and C++
* Delete benchmarks for languages supported by other repositories
* Bazelfying benchmark tests
* Bazelfying python
Use upb's system python rule instead of branching tensorflow
* Bazelfying Ruby
* Bazelfying C#
* Bazelfying Objective-c
* Bazelfying Kokoro mac builds
* Bazelfying Kokoro linux builds
* Deleting all deprecated files from autotools cleanup
This boils down to Makefile.am and tests.sh and all of their remaining references
* Cleanup after PR reorganizing
- Enable 32 bit tests
- Move conformance tests back
- Use select statements to select alternate runtimes
- Add internal prefixes to proto library macros
* Updating READMEs to use bazel instead of autotools.
* Bazelfying Kokoro release builds
* First round of review fixes
* Second round of review fixes
* Third round of review fixes
* Filtering out conformance tests from Bazel on Windows (b/241484899)
* Add version metadata that was previously scraped from configure.ac
* fixing typo from previous fix
* Adding ruby version tests
* Bumping pinned upb version, and adding tests to python CI
unistack-org/micro (microservices framework) uses protoc-gen-go-micro generator that has extension support for additional framework related options.
It is currently not using any registered extension number, so i want to stabilise this and i think that this is a good thing.
See here for an example of the extenstion in action.
Co-authored-by: Adam Cozzette <acozzette@google.com>
Connor
Yannic
Jeff Gulbronson
Yamamoto, Hirotaka
Mike Kruskal
James Brock
Rob Shakir
Protobuf Team Bot
Joshua Humphries
Martijn Vels
yksten
Alexander Timin
Dennis
Ted Pudlik
deannagarcia
Nipunn Koorapati
Mike Kruskal
Sam Nobs
Matt Kulukundis
Iwan Aucamp
theodorerose
Dennis Shao
Jorg Brown
Dilan Sachintha Nayanajith
Sandy Zhang
David L. Jones
Chan Wen Xu
Vegard Storheil Eriksen
Joshua Haberman
cui fliter
Elliotte Rusty Harold
Neakxs
noahdietz
Vasiliy Tolstov
Jeff Sawatzky
Gary Peck
Darly Paredes
yeqown
Adam Cozzette
Martin Schröder
idodod
BartH
Gregory Haskins
Dane Harrigan
JongChan Choi