aboutsummaryrefslogtreecommitdiff
path: root/CHANGES.txt
diff options
context:
space:
mode:
authorFeng Xiao <xfxyjwf@gmail.com>2014-12-09 11:57:52 -0800
committerFeng Xiao <xfxyjwf@gmail.com>2014-12-09 11:57:52 -0800
commit9104da3261db96779e80f4713a50f5d19921ade8 (patch)
tree2f4739161c5a896c36f62bd2922687c489666b7d /CHANGES.txt
parentbe20ae0b6975071563ecc61f8372fd7936f174ed (diff)
downloadprotobuf-9104da3261db96779e80f4713a50f5d19921ade8.tar.gz
protobuf-9104da3261db96779e80f4713a50f5d19921ade8.tar.bz2
protobuf-9104da3261db96779e80f4713a50f5d19921ade8.zip
Down-integrate from internal code base.
Diffstat (limited to 'CHANGES.txt')
-rw-r--r--CHANGES.txt104
1 files changed, 104 insertions, 0 deletions
diff --git a/CHANGES.txt b/CHANGES.txt
index 0d0ac814..0d4ce0ec 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,3 +1,107 @@
+2014-12-01 version 3.0.0-alpha-1 (C++/Java):
+
+ General
+ * Introduced Protocol Buffers language version 3 (aka proto3).
+
+ When protobuf was initially opensourced it implemented Protocol Buffers
+ language version 2 (aka proto2), which is why the version number
+ started from v2.0.0. From v3.0.0, a new language version (proto3) is
+ introduced while the old version (proto2) will continue to be supported.
+
+ The main intent of introducing proto3 is to clean up protobuf before
+ pushing the language as the foundation of Google's new API platform.
+ In proto3, the language is simplified, both for ease of use and to
+ make it available in a wider range of programming languages. At the
+ same time a few features are added to better support common idioms
+ found in APIs.
+
+ The following are the main new features in language version 3:
+
+ 1. Removal of field presence logic for primitive value fields, removal
+ of required fields, and removal of default values. This makes proto3
+ significantly easier to implement with open struct representations,
+ as in languages like Android Java, Objective C, or Go.
+ 2. Removal of unknown fields.
+ 3. Removal of extensions, which are instead replaced by a new standard
+ type called Any.
+ 4. Fix semantics for unknown enum values.
+ 5. Addition of maps.
+ 6. Addition of a small set of standard types for representation of time,
+ dynamic data, etc.
+ 7. A well-defined encoding in JSON as an alternative to binary proto
+ encoding.
+
+ This release (v3.0.0-alpha-1) includes partial proto3 support for C++ and
+ Java. Items 6 (well-known types) and 7 (JSON format) in the above feature
+ list are not impelmented.
+
+ A new notion "syntax" is introduced to specify whether a .proto file
+ uses proto2 or proto3:
+
+ // foo.proto
+ syntax = "proto3";
+ message Bar {...}
+
+ If omitted, the protocol compiler will generate a warning and "proto2" will
+ be used as the default. This warning will be turned into an error in a
+ future release.
+
+ We recommend that new Protocol Buffers users use proto3. However, we do not
+ generally recommend that existing users migrate from proto2 from proto3 due
+ to API incompatibility, and we will continue to support proto2 for a long
+ time.
+
+ * Added support for map fields (implemented in C++/Java for both proto2 and
+ proto3).
+
+ Map fields can be declared using the following syntax:
+
+ message Foo {
+ map<string, string> values = 1;
+ }
+
+ Data of a map field will be stored in memory as an unordered map and it
+ can be accessed through generated accessors.
+
+ C++
+ * Added arena allocation support (for both proto2 and proto3).
+
+ Profiling shows memory allocation and deallocation constitutes a significant
+ fraction of CPU-time spent in protobuf code and arena allocation is a
+ technique introduced to reduce this cost. With arena allocation, new
+ objects will be allocated from a large piece of preallocated memory and
+ deallocation of these objects is almost free. Early adoption shows 20% to
+ 50% improvement in some Google binaries.
+
+ To enable arena support, add the following option to your .proto file:
+
+ option cc_enable_arenas = true;
+
+ Protocol compiler will generate additional code to make the generated
+ message classes work with arenas. This does not change the existing API
+ of protobuf messages and does not affect wire format. Your existing code
+ should continue to work after adding this option. In the future we will
+ make this option enabled by default.
+
+ To actually take advantage of arena allocation, you need to use the arena
+ APIs when creating messages. A quick example of using the arena API:
+
+ {
+ google::protobuf::Arena arena;
+ // Allocate a protobuf message in the arena.
+ MyMessage* message = Arena::CreateMessage<MyMessage>(&arena);
+ // All submessages will be allocated in the same arena.
+ if (!message->ParseFromString(data)) {
+ // Deal with malformed input data.
+ }
+ // Must not delete the message here. It will be deleted automatically
+ // when the arena is destroyed.
+ }
+
+ Currently arena does not work with map fields. Enabling arena in a .proto
+ file containing map fields will result in compile errors in the generated
+ code. This will be addressed in a future release.
+
2014-10-20 version 2.6.1:
C++