OLD | NEW |
1 2015-05-25 version 3.0.0-alpha-3 (Objective-C/C#): | 1 2012-09-19 version 2.5.0: |
2 General | |
3 * Introduced two new language implementations (Objective-C, C#) to proto3. | |
4 * Explicit "optional" keyword are disallowed in proto3 syntax, as fields are | |
5 optional by default. | |
6 * Group fields are no longer supported in proto3 syntax. | |
7 * Changed repeated primitive fields to use packed serialization by default in | |
8 proto3 (implemented for C++, Java, Python in this release). The user can | |
9 still disable packed serialization by setting packed to false for now. | |
10 * Added well-known type protos (any.proto, empty.proto, timestamp.proto, | |
11 duration.proto, etc.). Users can import and use these protos just like | |
12 regular proto files. Addtional runtime support will be added for them in | |
13 future releases (in the form of utility helper functions, or having them | |
14 replaced by language specific types in generated code). | |
15 * Added a "reserved" keyword in both proto2 and proto3 syntax. User can use | |
16 this keyword to declare reserved field numbers and names to prevent them | |
17 from being reused by other fields in the same message. | |
18 | |
19 To reserve field numbers, add a reserved declaration in your message: | |
20 | |
21 message TestMessage { | |
22 reserved 2, 15, 9 to 11, 3; | |
23 } | |
24 | |
25 This reserves field numbers 2, 3, 9, 10, 11 and 15. If a user uses any of | |
26 these as field numbers, the protocol buffer compiler will report an error. | |
27 | |
28 Field names can also be reserved: | |
29 | |
30 message TestMessage { | |
31 reserved "foo", "bar"; | |
32 } | |
33 | |
34 * Various bug fixes since 3.0.0-alpha-2 | |
35 | |
36 Objective-C | |
37 Objective-C includes a code generator and a native objective-c runtime | |
38 library. By adding “--objc_out” to protoc, the code generator will generate | |
39 a header(*.pbobjc.h) and an implementation file(*.pbobjc.m) for each proto | |
40 file. | |
41 | |
42 In this first release, the generated interface provides: enums, messages, | |
43 field support(single, repeated, map, oneof), proto2 and proto3 syntax | |
44 support, parsing and serialization. It’s compatible with ARC and non-ARC | |
45 usage. Besides, user can also access it via the swift bridging header. | |
46 | |
47 See objectivec/README.md for details. | |
48 | |
49 C# | |
50 * C# protobufs are based on project | |
51 https://github.com/jskeet/protobuf-csharp-port. The original project was | |
52 frozen and all the new development will happen here. | |
53 * Codegen plugin for C# was completely rewritten to C++ and is now an | |
54 intergral part of protoc. | |
55 * Some refactorings and cleanup has been applied to the C# runtime library. | |
56 * Only proto2 is supported in C# at the moment, proto3 support is in | |
57 progress and will likely bring significant breaking changes to the API. | |
58 | |
59 See csharp/README.md for details. | |
60 | |
61 C++ | |
62 * Added runtime support for Any type. To use Any in your proto file, first | |
63 import the definition of Any: | |
64 | |
65 // foo.proto | |
66 import "google/protobuf/any.proto"; | |
67 message Foo { | |
68 google.protobuf.Any any_field = 1; | |
69 } | |
70 message Bar { | |
71 int32 value = 1; | |
72 } | |
73 | |
74 Then in C++ you can access the Any field using PackFrom()/UnpackTo() | |
75 methods: | |
76 | |
77 Foo foo; | |
78 Bar bar = ...; | |
79 foo.mutable_any_field()->PackFrom(bar); | |
80 ... | |
81 if (foo.any_field().IsType<Bar>()) { | |
82 foo.any_field().UnpackTo(&bar); | |
83 ... | |
84 } | |
85 * In text format, entries of a map field will be sorted by key. | |
86 | |
87 Java | |
88 * Continued optimizations on the lite runtime to improve performance for | |
89 Android. | |
90 | |
91 Python | |
92 * Added map support. | |
93 - maps now have a dict-like interface (msg.map_field[key] = value) | |
94 - existing code that modifies maps via the repeated field interface | |
95 will need to be updated. | |
96 | |
97 Ruby | |
98 * Improvements to RepeatedField's emulation of the Ruby Array API. | |
99 * Various speedups and internal cleanups. | |
100 | |
101 2015-02-26 version 3.0.0-alpha-2 (Python/Ruby/JavaNano): | |
102 General | |
103 * Introduced three new language implementations (Ruby, JavaNano, and | |
104 Python) to proto3. | |
105 * Various bug fixes since 3.0.0-alpha-1 | |
106 | |
107 Python: | |
108 Python has received several updates, most notably support for proto3 | |
109 semantics in any .proto file that declares syntax="proto3". | |
110 Messages declared in proto3 files no longer represent field presence | |
111 for scalar fields (number, enums, booleans, or strings). You can | |
112 no longer call HasField() for such fields, and they are serialized | |
113 based on whether they have a non-zero/empty/false value. | |
114 | |
115 One other notable change is in the C++-accelerated implementation. | |
116 Descriptor objects (which describe the protobuf schema and allow | |
117 reflection over it) are no longer duplicated between the Python | |
118 and C++ layers. The Python descriptors are now simple wrappers | |
119 around the C++ descriptors. This change should significantly | |
120 reduce the memory usage of programs that use a lot of message | |
121 types. | |
122 | |
123 Ruby: | |
124 We have added proto3 support for Ruby via a native C extension. | |
125 | |
126 The Ruby extension itself is included in the ruby/ directory, and details on | |
127 building and installing the extension are in ruby/README.md. The extension | |
128 will also be published as a Ruby gem. Code generator support is included as | |
129 part of `protoc` with the `--ruby_out` flag. | |
130 | |
131 The Ruby extension implements a user-friendly DSL to define message types | |
132 (also generated by the code generator from `.proto` files). Once a message | |
133 type is defined, the user may create instances of the message that behave in | |
134 ways idiomatic to Ruby. For example: | |
135 | |
136 - Message fields are present as ordinary Ruby properties (getter method | |
137 `foo` and setter method `foo=`). | |
138 - Repeated field elements are stored in a container that acts like a native | |
139 Ruby array, and map elements are stored in a container that acts like a | |
140 native Ruby hashmap. | |
141 - The usual well-known methods, such as `#to_s`, `#dup`, and the like, are | |
142 present. | |
143 | |
144 Unlike several existing third-party Ruby extensions for protobuf, this | |
145 extension is built on a "strongly-typed" philosophy: message fields and | |
146 array/map containers will throw exceptions eagerly when values of the | |
147 incorrect type are inserted. | |
148 | |
149 See ruby/README.md for details. | |
150 | |
151 JavaNano: | |
152 JavaNano is a special code generator and runtime library designed especially | |
153 for resource-restricted systems, like Android. It is very resource-friendly | |
154 in both the amount of code and the runtime overhead. Here is an an overview | |
155 of JavaNano features compared with the official Java protobuf: | |
156 | |
157 - No descriptors or message builders. | |
158 - All messages are mutable; fields are public Java fields. | |
159 - For optional fields only, encapsulation behind setter/getter/hazzer/ | |
160 clearer functions is opt-in, which provide proper 'has' state support. | |
161 - For proto2, if not opted in, has state (field presence) is not available. | |
162 Serialization outputs all fields not equal to their defaults. | |
163 The behavior is consistent with proto3 semantics. | |
164 - Required fields (proto2 only) are always serialized. | |
165 - Enum constants are integers; protection against invalid values only | |
166 when parsing from the wire. | |
167 - Enum constants can be generated into container interfaces bearing | |
168 the enum's name (so the referencing code is in Java style). | |
169 - CodedInputByteBufferNano can only take byte[] (not InputStream). | |
170 - Similarly CodedOutputByteBufferNano can only write to byte[]. | |
171 - Repeated fields are in arrays, not ArrayList or Vector. Null array | |
172 elements are allowed and silently ignored. | |
173 - Full support for serializing/deserializing repeated packed fields. | |
174 - Support extensions (in proto2). | |
175 - Unset messages/groups are null, not an immutable empty default | |
176 instance. | |
177 - toByteArray(...) and mergeFrom(...) are now static functions of | |
178 MessageNano. | |
179 - The 'bytes' type translates to the Java type byte[]. | |
180 | |
181 See javanano/README.txt for details. | |
182 | |
183 2014-12-01 version 3.0.0-alpha-1 (C++/Java): | |
184 | |
185 General | |
186 * Introduced Protocol Buffers language version 3 (aka proto3). | |
187 | |
188 When protobuf was initially opensourced it implemented Protocol Buffers | |
189 language version 2 (aka proto2), which is why the version number | |
190 started from v2.0.0. From v3.0.0, a new language version (proto3) is | |
191 introduced while the old version (proto2) will continue to be supported. | |
192 | |
193 The main intent of introducing proto3 is to clean up protobuf before | |
194 pushing the language as the foundation of Google's new API platform. | |
195 In proto3, the language is simplified, both for ease of use and to | |
196 make it available in a wider range of programming languages. At the | |
197 same time a few features are added to better support common idioms | |
198 found in APIs. | |
199 | |
200 The following are the main new features in language version 3: | |
201 | |
202 1. Removal of field presence logic for primitive value fields, removal | |
203 of required fields, and removal of default values. This makes proto3 | |
204 significantly easier to implement with open struct representations, | |
205 as in languages like Android Java, Objective C, or Go. | |
206 2. Removal of unknown fields. | |
207 3. Removal of extensions, which are instead replaced by a new standard | |
208 type called Any. | |
209 4. Fix semantics for unknown enum values. | |
210 5. Addition of maps. | |
211 6. Addition of a small set of standard types for representation of time, | |
212 dynamic data, etc. | |
213 7. A well-defined encoding in JSON as an alternative to binary proto | |
214 encoding. | |
215 | |
216 This release (v3.0.0-alpha-1) includes partial proto3 support for C++ and | |
217 Java. Items 6 (well-known types) and 7 (JSON format) in the above feature | |
218 list are not impelmented. | |
219 | |
220 A new notion "syntax" is introduced to specify whether a .proto file | |
221 uses proto2 or proto3: | |
222 | |
223 // foo.proto | |
224 syntax = "proto3"; | |
225 message Bar {...} | |
226 | |
227 If omitted, the protocol compiler will generate a warning and "proto2" will | |
228 be used as the default. This warning will be turned into an error in a | |
229 future release. | |
230 | |
231 We recommend that new Protocol Buffers users use proto3. However, we do not | |
232 generally recommend that existing users migrate from proto2 from proto3 due | |
233 to API incompatibility, and we will continue to support proto2 for a long | |
234 time. | |
235 | |
236 * Added support for map fields (implemented in C++/Java for both proto2 and | |
237 proto3). | |
238 | |
239 Map fields can be declared using the following syntax: | |
240 | |
241 message Foo { | |
242 map<string, string> values = 1; | |
243 } | |
244 | |
245 Data of a map field will be stored in memory as an unordered map and it | |
246 can be accessed through generated accessors. | |
247 | |
248 C++ | |
249 * Added arena allocation support (for both proto2 and proto3). | |
250 | |
251 Profiling shows memory allocation and deallocation constitutes a significant | |
252 fraction of CPU-time spent in protobuf code and arena allocation is a | |
253 technique introduced to reduce this cost. With arena allocation, new | |
254 objects will be allocated from a large piece of preallocated memory and | |
255 deallocation of these objects is almost free. Early adoption shows 20% to | |
256 50% improvement in some Google binaries. | |
257 | |
258 To enable arena support, add the following option to your .proto file: | |
259 | |
260 option cc_enable_arenas = true; | |
261 | |
262 Protocol compiler will generate additional code to make the generated | |
263 message classes work with arenas. This does not change the existing API | |
264 of protobuf messages and does not affect wire format. Your existing code | |
265 should continue to work after adding this option. In the future we will | |
266 make this option enabled by default. | |
267 | |
268 To actually take advantage of arena allocation, you need to use the arena | |
269 APIs when creating messages. A quick example of using the arena API: | |
270 | |
271 { | |
272 google::protobuf::Arena arena; | |
273 // Allocate a protobuf message in the arena. | |
274 MyMessage* message = Arena::CreateMessage<MyMessage>(&arena); | |
275 // All submessages will be allocated in the same arena. | |
276 if (!message->ParseFromString(data)) { | |
277 // Deal with malformed input data. | |
278 } | |
279 // Must not delete the message here. It will be deleted automatically | |
280 // when the arena is destroyed. | |
281 } | |
282 | |
283 Currently arena does not work with map fields. Enabling arena in a .proto | |
284 file containing map fields will result in compile errors in the generated | |
285 code. This will be addressed in a future release. | |
286 | |
287 2014-10-20 version 2.6.1: | |
288 | |
289 C++ | |
290 * Added atomicops support for Solaris. | |
291 * Released memory allocated by InitializeDefaultRepeatedFields() and | |
292 GetEmptyString(). Some memory sanitizers reported them as memory leaks. | |
293 | |
294 Java | |
295 * Updated DynamicMessage.setField() to handle repeated enum values | |
296 correctly. | |
297 * Fixed a bug that caused NullPointerException to be thrown when | |
298 converting manually constructed FileDescriptorProto to | |
299 FileDescriptor. | |
300 | |
301 Python | |
302 * Fixed WhichOneof() to work with de-serialized protobuf messages. | |
303 * Fixed a missing file problem of Python C++ implementation. | |
304 | |
305 2014-08-15 version 2.6.0: | |
306 | |
307 General | |
308 * Added oneofs(unions) feature. Fields in the same oneof will share | |
309 memory and at most one field can be set at the same time. Use the | |
310 oneof keyword to define a oneof like: | |
311 message SampleMessage { | |
312 oneof test_oneof { | |
313 string name = 4; | |
314 YourMessage sub_message = 9; | |
315 } | |
316 } | |
317 * Files, services, enums, messages, methods and enum values can be marked | |
318 as deprecated now. | |
319 * Added Support for list values, including lists of mesaages, when | |
320 parsing text-formatted protos in C++ and Java. | |
321 For example: foo: [1, 2, 3] | |
322 | |
323 C++ | |
324 * Enhanced customization on TestFormat printing. | |
325 * Added SwapFields() in reflection API to swap a subset of fields. | |
326 Added SetAllocatedMessage() in reflection API. | |
327 * Repeated primitive extensions are now packable. The | |
328 [packed=true] option only affects serializers. Therefore, it is | |
329 possible to switch a repeated extension field to packed format | |
330 without breaking backwards-compatibility. | |
331 * Various speed optimizations. | |
332 | |
333 Java | |
334 * writeTo() method in ByteString can now write a substring to an | |
335 output stream. Added endWith() method for ByteString. | |
336 * ByteString and ByteBuffer are now supported in CodedInputStream | |
337 and CodedOutputStream. | |
338 * java_generate_equals_and_hash can now be used with the LITE_RUNTIME. | |
339 | |
340 Python | |
341 * A new C++-backed extension module (aka "cpp api v2") that replaces the | |
342 old ("cpp api v1") one. Much faster than the pure Python code. This one | |
343 resolves many bugs and is recommended for general use over the | |
344 pure Python when possible. | |
345 * Descriptors now have enum_types_by_name and extension_types_by_name dict | |
346 attributes. | |
347 * Support for Python 3. | |
348 | |
349 2013-02-27 version 2.5.0: | |
350 | 2 |
351 General | 3 General |
352 * New notion "import public" that allows a proto file to forward the content | 4 * New notion "import public" that allows a proto file to forward the content |
353 it imports to its importers. For example, | 5 it imports to its importers. For example, |
354 // foo.proto | 6 // foo.proto |
355 import public "bar.proto"; | 7 import public "bar.proto"; |
356 import "baz.proto"; | 8 import "baz.proto"; |
357 | 9 |
358 // qux.proto | 10 // qux.proto |
359 import "foo.proto"; | 11 import "foo.proto"; |
360 // Stuff defined in bar.proto may be used in this file, but stuff from | 12 // Stuff defined in bar.proto may be used in this file, but stuff from |
361 // baz.proto may NOT be used without importing it explicitly. | 13 // baz.proto may NOT be used without importing it explicitly. |
362 This is useful for moving proto files. To move a proto file, just leave | 14 This is useful for moving proto files. To move a proto file, just leave |
363 a single "import public" in the old proto file. | 15 a single "import public" in the old proto file. |
364 * New enum option "allow_alias" that specifies whether different symbols can | 16 * New enum option "allow_alias" that specifies whether different symbols can |
365 be assigned the same numeric value. Default value is "true". Setting it to | 17 be assigned the same numeric value. Default value is "true". Setting it to |
366 false causes the compiler to reject enum definitions where multiple symbols | 18 false causes the compiler to reject enum definitions where multiple symbols |
367 have the same numeric value. | 19 have the same numeric value. |
368 Note: We plan to flip the default value to "false" in a future release. | |
369 Projects using enum aliases should set the option to "true" in their .proto | |
370 files. | |
371 | 20 |
372 C++ | 21 C++ |
373 * New generated method set_allocated_foo(Type* foo) for message and string | 22 * New generated method set_allocated_foo(Type* foo) for message and string |
374 fields. This method allows you to set the field to a pre-allocated object | 23 fields. This method allows you to set the field to a pre-allocated object |
375 and the containing message takes the ownership of that object. | 24 and the containing message takes the ownership of that object. |
376 * Added SetAllocatedExtension() and ReleaseExtension() to extensions API. | 25 * Added SetAllocatedExtension() and ReleaseExtension() to extensions API. |
377 * Custom options are now formatted correctly when descriptors are printed in | 26 * Custom options are now formatted correctly when descriptors are printed in |
378 text format. | 27 text format. |
379 * Various speed optimizations. | 28 * Various speed optimizations. |
380 | 29 |
381 Java | 30 Java |
382 * Comments in proto files are now collected and put into generated code as | 31 * Comments in proto files are now collected and put into generated code as |
383 comments for corresponding classes and data members. | 32 comments for corresponding classes and data members. |
384 * Added Parser to parse directly into messages without a Builder. For | 33 * Added Parser to parse directly into messages without a Builder. For |
385 example, | 34 example, |
386 Foo foo = Foo.PARSER.ParseFrom(input); | 35 Foo foo = Foo.getParser().ParseFrom(input); |
387 Using Parser is ~25% faster than using Builder to parse messages. | 36 Using Parser is ~25% faster than using Builder to parse messages. |
388 * Added getters/setters to access the underlying ByteString of a string field | 37 * Added getters/setters to access the underlying ByteString of a string field |
389 directly. | 38 directly. |
390 * ByteString now supports more operations: substring(), prepend(), and | 39 * ByteString now supports more operations: substring(), prepend(), and |
391 append(). The implementation of ByteString uses a binary tree structure | 40 append(). The implementation of ByteString uses a binary tree structure |
392 to support these operations efficiently. | 41 to support these operations efficiently. |
393 * New method findInitializationErrors() that lists all missing required | 42 * New method findInitializationErrors() that lists all missing required |
394 fields. | 43 fields. |
395 * Various code size and speed optimizations. | 44 * Various code size and speed optimizations. |
396 | 45 |
(...skipping 473 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... |
870 contain extra zeros. | 519 contain extra zeros. |
871 * Fix Python service CallMethod() implementation. | 520 * Fix Python service CallMethod() implementation. |
872 | 521 |
873 Other | 522 Other |
874 * Improved readmes. | 523 * Improved readmes. |
875 * VIM syntax highlighting improvements. | 524 * VIM syntax highlighting improvements. |
876 | 525 |
877 2008-07-07 version 2.0.0: | 526 2008-07-07 version 2.0.0: |
878 | 527 |
879 * First public release. | 528 * First public release. |
OLD | NEW |