Right, we are still maintaining both proto2 and proto3 and plan to keep supporting both flavors indefinitely.
On Tue, Jan 21, 2020 at 4:09 AM Luciano Perezzini <[email protected]> wrote: > This is still true, Adam? Google would not deprecate Proto2, and Proto2 > and Proto3 are just different flavors of Protocol Buffers? Me and my team > are about to start a brand new project using Protocol Buffers and the lack > of missing value check properties in Proto3 is a BIG concern. > > Thanks in advance, and I wait for your response. > > Regards! > > On Tuesday, December 19, 2017 at 5:59:44 PM UTC-3, Adam Cozzette wrote: >> >> Yes, we are planning on supporting proto2 pretty much forever. Within >> Google we have a huge amount of code using proto2 and for the most part >> we're not attempting to migrate existing code to proto3. Language support >> is one reason to go with proto3, but it's also simpler and more convenient >> for working with JSON. >> >> On Tue, Dec 19, 2017 at 12:13 PM, Josh Humphries <[email protected]> >> wrote: >> >>> Adam, >>> I understand there is no *current* plan to deprecate proto2. But is it >>> really expected to be supported forever? >>> >>> If that's the case, I suppose the only reason to choose proto3 over >>> proto2 (if you happen to want the features and semantics of proto2) might >>> be that not all languages/runtimes have support for proto2. Though I >>> thought this was a short/medium-term issue. If all languages/runtimes >>> eventually support both, it seems like a strange decision to continue >>> supporting both indefinitely. >>> >>> >>> ---- >>> *Josh Humphries* >>> [email protected] >>> >>> On Tue, Dec 19, 2017 at 2:23 PM, Adam Cozzette <[email protected]> >>> wrote: >>> >>>> Actually we have no plans to deprecate proto2 and we are still actively >>>> developing it, so you can really choose either one without having to worry >>>> about support going away. >>>> >>>> On Sat, Dec 16, 2017 at 11:42 AM, Josh Humphries <[email protected] >>>> > wrote: >>>> >>>>> I think proto3 was intended to be simpler -- an evolution of protobuf >>>>> in a direction that is more refined and elides superfluous features. >>>>> Eventually (though not likely any time soon), support for proto2 will go >>>>> away. >>>>> >>>>> The main omission in proto3 that I personally felt strongly about was >>>>> the lack of preserving unknown fields. But that functionality has been >>>>> restored for many languages/runtimes in 3.5 (and coming soon, hopefully, >>>>> for Go and the others). >>>>> >>>>> All of the other omissions in proto3 have alternate >>>>> solutions/work-arounds that aren't baked into the language (like wrapper >>>>> types and Any), which shows that these features didn't truly need to be >>>>> language features to begin with. So it allows the language itself to >>>>> remain >>>>> simple, which means libraries/tooling are simpler to build on top. >>>>> >>>>> So a big advantage of proto3 is simplicity (and for some >>>>> languages/runtimes, that will translate into improved performance). And >>>>> another advantage is future compatibility (since, in all likelihood, >>>>> proto2 >>>>> will eventually go away.) >>>>> >>>>> >>>>> If creating new files, it makes sense to use proto3. If you already >>>>> have a corpus of proto2 files, a reasonable migration path forward is to >>>>> start evolving them to proto3 (or, if the languages/runtimes you use don't >>>>> yet preserve unrecognized fields, wait for that functionality to be fully >>>>> implemented everywhere and then start evolving). >>>>> >>>>> - Make required fields optional. Required fields have always been >>>>> dangerous. If a field is required in your protocol, it can be enforced >>>>> in >>>>> application code instead of in the de-serialization logic of the >>>>> protobuf >>>>> runtime. >>>>> - Use Any instead of extensions. An extension range can generally >>>>> be replaced with a repeated Any field. Extensions with scalar types >>>>> will >>>>> have to be "boxed" into single-field messages. >>>>> - Use wrapper types for scalar fields where absence must be >>>>> distinguishable from zero. >>>>> - Usages of default values can be changed to use wrapper types and >>>>> application logic that decides non-zero values to use when the field >>>>> is not >>>>> present. >>>>> - Groups should be replaced with nested messages. >>>>> >>>>> Once a file is no longer using any proto2 features, it can be changed >>>>> to proto3 syntax. Unfortunately, there is not yet a way to incrementally >>>>> move to proto3. Once you change the syntax of the file, the generated code >>>>> will change, and all clients of that generated code must be changed >>>>> atomically in order to compile (at least for languages/runtimes where >>>>> generated code for the two syntaxes is materially different/incompatible). >>>>> I would hope that this is something that will be addressed in future >>>>> versions of protobuf, to facilitate migrations away from proto2. >>>>> >>>>> >>>>> ---- >>>>> *Josh Humphries* >>>>> [email protected] >>>>> >>>>> On Sat, Dec 16, 2017 at 2:17 PM, ajcurtis84 <[email protected]> >>>>> wrote: >>>>> >>>>>> Thank you everyone for all the great input! >>>>>> >>>>>> Based on this discussion, what is the advantage of using proto3? It >>>>>> appears that proto2 is more feature rich. JSON isn't a compelling >>>>>> reason.... >>>>>> >>>>>> Thanks >>>>>> >>>>>> -- >>>>>> 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 post to this group, send email to [email protected]. >>>>>> Visit this group at https://groups.google.com/group/protobuf. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> -- >>>>> 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 post to this group, send email to [email protected]. >>>>> Visit this group at https://groups.google.com/group/protobuf. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>> >> -- > 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 on the web visit > https://groups.google.com/d/msgid/protobuf/3e078cd3-ba3f-4ab0-a9a4-e8852f502045%40googlegroups.com > <https://groups.google.com/d/msgid/protobuf/3e078cd3-ba3f-4ab0-a9a4-e8852f502045%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 on the web visit https://groups.google.com/d/msgid/protobuf/CADqAXr4pfc-W7Qjez%2BzrKSZD%3DynJ2qfmH-ETsaEUOq5nfFjhpQ%40mail.gmail.com.
