Always nice to recognize a xoogler name 🙂 Broadly, the plan is for a future Edition number to have enums be treated as scoped by default, but with a feature setting that opts back in to current behavior for people who want to upgrade the Edition number of preexisting .proto files perfectly-behavior-preserving (behavior-preserving uprades should be tool assisted with a tool called Prototiller, whose OSS implementation is unfortunately still not stabilized yet as we are rewriting it to Go).
Scoped enums is close to the top of the candidates list for Edition 2026 which is targeted for 2026-Q3, but we don't have any firm commitments around Edition 2026 details at the moment. We don't intend to change the enum behavior on proto2/proto3/Edition-2023/Edition-2024 files (or even support an option there to do so), as our forward Editions strategy is to generally treat the behavior of older syntax IDL inputs as fixed as the way to avoid the ecosystem problems that come from even adding new options that old impls/infrastructure won't know about. So unfortunately anyone who plans to stay on Proto3 forever won't get the new goodness, you'll need to continue to just wrap each enum in an empty message if you want to avoid the stupid value name collision problems. > Is that actually on a roadmap anywhere? I don't see it in Issues. We mostly don't use Issues for tracking our roadmap work, primarily Issues is for handling external bugs/requests/discussion (unlike gRPC which has community-driven CNCF governance, Protobuf is still a Google project). If you want to open it on Issues so you can be notified when it moves forward, free to open and I'll tag the issue appropriately and we can try to remember to keep it up to date. Thanks! On Mon, Jan 5, 2026 at 8:49 AM Max Kanat-Alexander <[email protected]> wrote: > Hey proto team! :) The current docs say that scoped enums will be part of > a future edition. Is that actually on a roadmap anywhere? I don't see it in > Issues. I'm mostly just wondering if I should expect it by some vague date. > > I'm playing around with defining a configuration language based on a > strict subset of textproto, and scoped enums would help a ton so that users > could just write `state: ACTIVE` instead of the unintuitive `state: > STATE_ACTIVE` in their config files. I know that I can accomplish that > today by nesting enums inside of messages, but what I'm curious about is if > the future potential implementation of scoped enums will break backwards > compatibility with that in some way. > > -Max > > -- > You received this message because you are subscribed to the Google Groups > "Protocol Buffers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/protobuf/25fac6eb-2e5f-43e3-bcd2-3ec3df783b56n%40googlegroups.com > <https://groups.google.com/d/msgid/protobuf/25fac6eb-2e5f-43e3-bcd2-3ec3df783b56n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/protobuf/CAKRmVH-F-y28FtyUg0pFcF8xjEeN9OR%2BqWbVaq53nEkviMPa1Q%40mail.gmail.com.
