Project import generated by Copybara.

PiperOrigin-RevId: 744747856
Change-Id: Ibe9d1e30b313da5b3130fb2806d706147587e4ff

Author: Protocol Buffer Team

content/getting-started/pythontutorial.md

@@ -76,14 +76,16 @@ each field in the message. Here is the `.proto` file that defines your messages,
 `addressbook.proto`.
 
 ```proto
-syntax = "proto2";
+edition = "2023";
 
 package tutorial;
 
+option features.field_presence = EXPLICIT;
+
 message Person {
-  optional string name = 1;
-  optional int32 id = 2;
-  optional string email = 3;
+  string name = 1;
+  int32 id = 2;
+  string email = 3;
 
   enum PhoneType {
     PHONE_TYPE_UNSPECIFIED = 0;
@@ -93,8 +95,8 @@ message Person {
   }
 
   message PhoneNumber {
-    optional string number = 1;
-    optional PhoneType type = 2 [default = PHONE_TYPE_HOME];
+    string number = 1;
+    PhoneType type = 2 [default = PHONE_TYPE_HOME];
   }
 
   repeated PhoneNumber phones = 4;
@@ -135,39 +137,9 @@ less-commonly used optional elements. Each element in a repeated field requires
 re-encoding the tag number, so repeated fields are particularly good candidates
 for this optimization.
 
-Each field must be annotated with one of the following modifiers:
-
--   `optional`: the field may or may not be set. If an optional field value
-    isn't set, a default value is used. For simple types, you can specify your
-    own default value, as we've done for the phone number `type` in the example.
-    Otherwise, a system default is used: zero for numeric types, the empty
-    string for strings, false for bools. For embedded messages, the default
-    value is always the "default instance" or "prototype" of the message, which
-    has none of its fields set. Calling the accessor to get the value of an
-    optional (or required) field which has not been explicitly set always
-    returns that field's default value.
--   `repeated`: the field may be repeated any number of times (including zero).
-    The order of the repeated values will be preserved in the protocol buffer.
-    Think of repeated fields as dynamically sized arrays.
--   `required`: a value for the field must be provided, otherwise the message
-    will be considered "uninitialized". Serializing an uninitialized message
-    will raise an exception. Parsing an uninitialized message will fail. Other
-    than this, a required field behaves exactly like an optional field.
-
-{{% alert title="Important" color="warning" %}} **Required Is Forever**
-You should be very careful about marking fields as `required`. If at some point
-you wish to stop writing or sending a required field, it will be problematic to
-change the field to an optional field -- old readers will consider messages
-without this field to be incomplete and may reject or drop them unintentionally.
-You should consider writing application-specific custom validation routines for
-your buffers instead. Within Google, `required` fields are strongly disfavored;
-most messages defined in proto2 syntax use `optional` and `repeated` only.
-(Proto3 does not support `required` fields at all.)
-{{% /alert %}}
-
 You'll find a complete guide to writing `.proto` files -- including all the
 possible field types -- in the
-[Protocol Buffer Language Guide](/programming-guides/proto2).
+[Protocol Buffer Language Guide](/programming-guides/editions).
 Don't go looking for facilities similar to class inheritance, though -- protocol
 buffers don't do that.
 

content/installation.md

@@ -23,14 +23,15 @@ binaries, follow these instructions:
 
     ```sh
     PB_REL="https://github.com/protocolbuffers/protobuf/releases"
-    curl -LO $PB_REL/download/v< param protoc-version >/protoc-< param protoc-version >-linux-x86_64.zip
+    curl -LO $PB_REL/download/v30.2/protoc-30.2-linux-x86_64.zip
+
     ```
 
 2.  Unzip the file under `$HOME/.local` or a directory of your choice. For
     example:
 
     ```sh
-    unzip protoc-< param protoc-version >-linux-x86_64.zip -d $HOME/.local
+    unzip protoc-30.2-linux-x86_64.zip -d $HOME/.local
     ```
 
 3.  Update your environment's path variable to include the path to the `protoc`

content/programming-guides/editions.md

@@ -1003,7 +1003,11 @@ following rules:
     effect as if you had cast the number to that type in C++ (for example, if a
     64-bit number is read as an int32, it will be truncated to 32 bits).
 *   `sint32` and `sint64` are compatible with each other but are *not*
-    compatible with the other integer types.
+    compatible with the other integer types. If the value written was between
+    INT_MIN and INT_MAX inclusive it will parse as the same value with either
+    type. If an sint64 value was written outside of that range and parsed as an
+    sint32, the varint is truncated to 32 bits and then zigzag decoding occurs
+    (which will cause a different value to be observed).
 *   `string` and `bytes` are compatible as long as the bytes are valid UTF-8.
 *   Embedded messages are compatible with `bytes` if the bytes contain an
     encoded instance of the message.

content/programming-guides/proto2.md

@@ -1056,7 +1056,11 @@ following rules:
     effect as if you had cast the number to that type in C++ (for example, if a
     64-bit number is read as an int32, it will be truncated to 32 bits).
 *   `sint32` and `sint64` are compatible with each other but are *not*
-    compatible with the other integer types.
+    compatible with the other integer types. If the value written was between
+    INT_MIN and INT_MAX inclusive it will parse as the same value with either
+    type. If an sint64 value was written outside of that range and parsed as an
+    sint32, the varint is truncated to 32 bits and then zigzag decoding occurs
+    (which will cause a different value to be observed).
 *   `string` and `bytes` are compatible as long as the bytes are valid UTF-8.
 *   Embedded messages are compatible with `bytes` if the bytes contain an
     encoded instance of the message.

content/programming-guides/proto3.md

@@ -879,9 +879,14 @@ Instead of moving the `.proto` file directly and updating all the call sites in
 a single change, you can put a placeholder `.proto` file in the old location to
 forward all the imports to the new location using the `import public` notion.
 
-**Note that the public import functionality is not available in Java, Kotlin,
-TypeScript, JavaScript, GCL, as well as C++ targets that use protobuf static
-reflection.**
+**Note:** The public import functionality available in Java is most effective
+when moving an entire .proto file or when using `java_multiple_files = true`. In
+these cases, generated names remain stable, avoiding the need to update
+references in your code. While technically functional when moving a subset of a
+.proto file without `java_multiple_files = true`, doing so requires simultaneous
+updates to many references, thus might not significantly ease migration. The
+functionality is not available in Kotlin, TypeScript, JavaScript, GCL, or with
+C++ targets that use protobuf static reflection.
 
 `import public` dependencies can be transitively relied upon by any code
 importing the proto containing the `import public` statement. For example:
@@ -1006,7 +1011,11 @@ following rules:
     effect as if you had cast the number to that type in C++ (for example, if a
     64-bit number is read as an int32, it will be truncated to 32 bits).
 *   `sint32` and `sint64` are compatible with each other but are *not*
-    compatible with the other integer types.
+    compatible with the other integer types. If the value written was between
+    INT_MIN and INT_MAX inclusive it will parse as the same value with either
+    type. If an sint64 value was written outside of that range and parsed as an
+    sint32, the varint is truncated to 32 bits and then zigzag decoding occurs
+    (which will cause a different value to be observed).
 *   `string` and `bytes` are compatible as long as the bytes are valid UTF-8.
 *   Embedded messages are compatible with `bytes` if the bytes contain an
     encoded instance of the message.

content/reference/protobuf/textformat-spec.md

@@ -171,12 +171,12 @@ escape = "\a"                        (* ASCII #7  (bell)                 *)
 
 Octal escape sequences consume up to three octal digits. Additional digits are
 passed through without escaping. For example, when unescaping the input `\1234`,
-the parser consumes three octal digits (123) to unescape the byte value 0x83
-(ASCII 'S') and the subsequent '4' passes through as the byte value 0x34 (ASCII
-'4'). To ensure correct parsing, express octal escape sequences with 3 octal
-digits, using leading zeros as needed, such as: `\000`, `\001`, `\063`, `\377`.
-Fewer than three digits are consumed when a non-numeric character follows the
-numeric characters, such as `\5Hello`.
+the parser consumes three octal digits (123) to unescape the byte value 0x53
+(ASCII 'S', 83 in decimal) and the subsequent '4' passes through as the byte
+value 0x34 (ASCII '4'). To ensure correct parsing, express octal escape
+sequences with 3 octal digits, using leading zeros as needed, such as: `\000`,
+`\001`, `\063`, `\377`. Fewer than three digits are consumed when a non-numeric
+character follows the numeric characters, such as `\5Hello`.
 
 Hexadecimal escape sequences consume up to two hexadecimal digits. For example,
 when unescaping `\x213`, the parser consumes only the first two digits (21) to

content/support/cross-version-runtime-guarantee.md

@@ -13,9 +13,9 @@ using the generated code. When these come from different releases of protobuf,
 we are in a "cross version runtime" situation.
 
 We intend to offer the following guarantees across all languages except
-[C++](#cpp). These are the default guarantees; however, owners of protobuf code
-generators and runtimes may explicitly override them with more specific
-guarantees for that language.
+[C++ and Rust](#cpp). These are the default guarantees; however, owners of
+protobuf code generators and runtimes may explicitly override them with more
+specific guarantees for that language.
 
 Protobuf cross-version usages outside the guarantees are **error-prone and not
 supported**. Version skews can lead to *flakes and undefined behaviors* that are
@@ -120,9 +120,10 @@ matrix:
 
 Coexistence of multiple major versions in the same process is **not** supported.
 
-## C++ Specific Guarantees {#cpp}
+## C++ and Rust Specific Guarantees {#cpp}
+
+Protobuf C++ and Rust disclaim all cross-runtime support and require an exact
+match between the generated code version and the runtime version at all times.
 
-Protobuf C++ disclaims all cross-runtime support and requires an exact match
-between its generated code version and its runtime version at all times.
 Additionally, Protobuf C++ makes no guarantees about ABI stability across any
 releases (major, minor, or micro).

content/support/version-support.md

@@ -121,7 +121,7 @@ Future plans are shown in *italics* and are subject to change.
     <td>25 May 2022</td>
     <td>31 Mar 2024</td>
   </tr>
-  <tr class="maintenance">
+  <tr class="end-of-life">
     <th>4.x</th>
     <td>16 Feb 2023</td>
     <td>31 Mar 2025</td>
@@ -178,7 +178,7 @@ Future plans are shown in *italics* and are subject to change.
     <td class="y25q3"></td>
     <td class="y25q4"></td>
   </tr>
-  <tr class="maintenance">
+  <tr class="end-of-life">
     <th>4.x</th>
     <td>22.x-25.x</td>
     <td class="y23q1 active">4.22</td>
@@ -194,7 +194,7 @@ Future plans are shown in *italics* and are subject to change.
     <td class="y25q3"></td>
     <td class="y25q4"></td>
   </tr>
-  <tr class="active">
+  <tr class="maintenance">
     <th>5.x</th>
     <td>26.x-29.x</td>
     <td class="y23q1"></td>
@@ -210,7 +210,7 @@ Future plans are shown in *italics* and are subject to change.
     <td class="y25q3 maintenance">5.29</td>
     <td class="y25q4 maintenance">5.29</td>
   </tr>
-  <tr class="future">
+  <tr class="active">
     <th>6.x</th>
     <td>30.x-33.x</td>
     <td class="y23q1"></td>
@@ -365,28 +365,28 @@ Future plans are shown in *italics* and are subject to change.
   <tr class="maintenance">
     <th>3.x</th>
     <td>16 Feb 2023</td>
-    <td>31 Mar 2026*</td>
+    <td>31 Mar 2027*</td>
   </tr>
   <tr class="active">
     <th>4.x</th>
     <td>13 Mar 2024</td>
-    <td>31 Mar 2027</td>
+    <td>31 Mar 2028</td>
   </tr>
   <tr class="future">
     <th>5.x</th>
-    <td>Q1 2026*</td>
-    <td>31 Mar 2028</td>
+    <td>Q1 2027*</td>
+    <td>31 Mar 2029</td>
   </tr>
 </table>
 
 {{% alert title="Note" color="note" %}}
-The maintenance support window for the Protobuf Java 3.x release will be 24
+The maintenance support window for the Protobuf Java 3.x release will be 36
 months rather than the typical 12 months for the final release in a major
-version line. Future major version updates (5.x, planned for Q1 2026) will adopt
+version line. Future major version updates (5.x, planned for Q1 2027) will adopt
 an improved
 ["rolling compatibility window"](/support/cross-version-runtime-guarantee/#major)
 that should allow a return to 12-month support windows. There will be no major
-version bump in Q1 2025.{{% /alert %}}
+version bumps in Q1 2025 and Q1 2026.{{% /alert %}}
 
 **Release support chart**
 
@@ -522,7 +522,7 @@ Future plans are shown in *italics* and are subject to change.
     <th class="y25q3"><span>25Q3</span></th>
     <th class="y25q4"><span>25Q4</span></th>
   </tr>
-  <tr class="active">
+  <tr class="maintenance">
     <th>3.x</th>
     <td>22.x-29.x</td>
     <td class="y23q1 active">3.22</td>
@@ -538,7 +538,7 @@ Future plans are shown in *italics* and are subject to change.
     <td class="y25q3 maintenance">3.29</td>
     <td class="y25q4 maintenance">3.29</td>
   </tr>
-  <tr class="future">
+  <tr class="active">
     <th>4.x</th>
     <td>30.x+</td>
     <td class="y23q1"></td>
@@ -592,7 +592,7 @@ Future plans are shown in *italics* and are subject to change.
     <th>Release date</th>
     <th>End of support</th>
   </tr>
-  <tr class="maintenance">
+  <tr class="end-of-life">
     <th>3.x</th>
     <td>16 Feb 2023</td>
     <td>31 Mar 2025</td>
@@ -623,7 +623,7 @@ Future plans are shown in *italics* and are subject to change.
     <th class="y25q3"><span>25Q3</span></th>
     <th class="y25q4"><span>25Q4</span></th>
   </tr>
-  <tr class="maintenance">
+  <tr class="end-of-life">
     <th>3.x</th>
     <td>22.x-25.x</td>
     <td class="y23q1 active">3.22</td>
@@ -701,7 +701,7 @@ Future plans are shown in *italics* and are subject to change.
     <th>Release date</th>
     <th>End of support</th>
   </tr>
-  <tr class="maintenance">
+  <tr class="end-of-life">
     <th>4.x</th>
     <td>16 Feb 2023</td>
     <td>31 Mar 2025</td>
@@ -737,7 +737,7 @@ Future plans are shown in *italics* and are subject to change.
     <th class="y25q3"><span>25Q3</span></th>
     <th class="y25q4"><span>25Q4</span></th>
   </tr>
-  <tr class="maintenance">
+  <tr class="end-of-life">
     <th>4.x</th>
     <td>22.x-25.x</td>
     <td class="y23q1 active">4.22</td>
@@ -753,7 +753,7 @@ Future plans are shown in *italics* and are subject to change.
     <td class="y25q3"></td>
     <td class="y25q4"></td>
   </tr>
-  <tr class="active">
+  <tr class="maintenance">
     <th>5.x</th>
     <td>26.x-29.x</td>
     <td class="y23q1"></td>
@@ -769,7 +769,7 @@ Future plans are shown in *italics* and are subject to change.
     <td class="y25q3 maintenance">5.29</td>
     <td class="y25q4 maintenance">5.29</td>
   </tr>
-  <tr class="future">
+  <tr class="active">
     <th>6.x</th>
     <td>30.x+</td>
     <td class="y23q1"></td>
@@ -831,7 +831,7 @@ Future plans are shown in *italics* and are subject to change.
     <th>Release date</th>
     <th>End of support</th>
   </tr>
-  <tr class="maintenance">
+  <tr class="end-of-life">
     <th>3.x</th>
     <td>16 Feb 2023</td>
     <td>31 Mar 2025</td>
@@ -862,7 +862,7 @@ Future plans are shown in *italics* and are subject to change.
     <th class="y25q3"><span>25Q3</span></th>
     <th class="y25q4"><span>25Q4</span></th>
   </tr>
-  <tr class="maintenance">
+  <tr class="end-of-life">
     <th>3.x</th>
     <td>22.x-25.x</td>
     <td class="y23q1 active">3.22</td>