News-Ankündigungen für Version 30.x

Änderungen, die für Protocol Buffers Version 30.x angekündigt wurden.

Die folgenden Ankündigungen sind spezifisch für Version 30.x, die am 4. März 2025 veröffentlicht wurde. Informationen, die chronologisch dargestellt sind, finden Sie unter News.

Die folgenden Abschnitte behandeln geplante brechende Änderungen in der v30-Version, die für 2025 Q1 erwartet wird. Ebenfalls enthalten sind einige Änderungen, die nicht brechend sind, aber möglicherweise Maßnahmen Ihrerseits erfordern. Diese beschreiben Änderungen, wie sie voraussichtlich implementiert werden, aber aufgrund der flexiblen Natur von Software werden einige dieser Änderungen möglicherweise nicht umgesetzt oder können von der Beschreibung in diesem Thema abweichen.

Änderungen in C++

C++ wird seine Hauptversion von 5.29.x auf 6.30.x anheben.

Descriptor APIs

v30 wird Rückgabetypen in Deskriptoren (wie full_name) auf absl::string_view aktualisieren. Dies ermöglicht Speicherersparnisse in Deskriptoren.

v28 hat das Makro PROTOBUF_FUTURE_STRING_VIEW_RETURN_TYPE eingeführt, das Sie in der Zwischenzeit verwenden können, um den aktualisierten Rückgabetyp vor der brechenden Veröffentlichung zu aktivieren. Die v30-Veröffentlichung wird den Standardwert ändern und das Makro entfernen.

ctype aus FieldDescriptor-Optionen entfernt

v30 wird die ctype aus den FieldDescriptor-Optionen nicht mehr verfügbar machen. Sie können stattdessen die API FieldDescriptor::cpp_string_type() verwenden, die in der v28-Veröffentlichung hinzugefügt wurde.

CMake-Submodule durch abgerufene Abhängigkeiten ersetzen

v30 wird Submodule entfernen und zum alten CMake-Muster von upb übergehen, Abhängigkeiten abzurufen.

Wenn Sie installierte Pakete verwenden, sind Sie nicht betroffen. Es könnte einige CMake-Workflows beeinträchtigen.

Debug-APIs ändern, um sensible Felder zu schwärzen

Wir planen, die Protobuf-Debug-APIs (einschließlich Protobuf AbslStringify, proto2::ShortFormat, proto2::Utf8Format, Message::DebugString, Message::ShortDebugString, Message::Utf8DebugString) in v30 zu ändern, um sensible Felder zu schwärzen, die mit debug_redact annotiert sind; die Ausgaben dieser APIs enthalten ein prozessspezifisches, zufälliges Präfix und sind daher nicht mehr mit Protobuf TextFormat Parsers parsierbar.

Lesen Sie mehr darüber im Nachrichtenartikel vom 21. November 2024.

Entfernen einer reflektionsbezogenen Funktion

Wir entfernen die folgende reflektionsbezogene Funktion: MutableRepeatedFieldRef<T>::Reserve().

Eine bevorstehende Leistungsverbesserung in RepeatedPtrField ist mit dieser API inkompatibel. Die Verbesserung soll den wiederholten Zugriff auf die Elemente von RepeatedPtrField beschleunigen, insbesondere den sequenziellen Zugriff.

Veraltete APIs entfernt

v30 wird die folgenden öffentlichen Laufzeit-APIs entfernen, die seit mindestens einer Minor- oder Major-Version als veraltet gekennzeichnet sind und veraltet oder ersetzt sind.

Arena::CreateMessage

API: Arena::CreateMessage

Ersatz: Arena::Create

Arena::GetArena

API: Arena::GetArena

Ersatz: value->GetArena()

RepeatedPtrField::ClearedCount

API: RepeatedPtrField::ClearedCount

Ersatz: Migration zu Arenen (Migrationsleitfaden).

JsonOptions

API: JsonOptions

Ersatz: JsonPrintOptions

Unterstützung für C++14 einstellen

Diese Veröffentlichung wird C++ 14 als minimale unterstützte Version einstellen und auf 17 anheben, gemäß der Foundational C++ Support-Matrix.

Gemäß unserer Richtlinien betrachten wir dies nicht als brechende Änderung.

ASAN-Vergiftung nach dem Leeren von Oneof-Nachrichten auf Arena einführen

Diese Änderung fügt eine Härtungsprüfung hinzu, die C++-Protobufs mit Arenen betrifft. Oneof-Nachrichten, die auf der Protobuf-Arena alloziert werden, werden nun im Debug-Modus geleert und im ASAN-Modus vergiftet. Nach dem Leeren stürzt ein zukünftiger Versuch, den Speicherbereich zu verwenden, in ASAN als Use-After-Free-Fehler ab.

Diese Implementierung erfordert C++17.

Unser C++ CocoaPods-Release einstellen

In v30 werden wir unser C++ CocoaPods-Release einstellen, das seit v4.x.x fehlerhaft ist. C++-Benutzer sollten stattdessen direkt unser GitHub-Release verwenden.

Änderungen in JRuby

v30 wird die Standardimplementierung für JRuby auf FFI umstellen, was für einige JRuby-Benutzer brechend sein kann.

Beachten Sie, dass diese Änderung keine Ruby-Major-Versionserhöhung bewirkt, da JRuby nicht offiziell unterstützt wird.

Änderungen in Python

Python wird seine Hauptversion von 5.29.x auf 6.30.x anheben.

Unterstützung für Python 3.8 einstellen

Gemäß unserer offiziellen Python-Supportrichtlinie werden wir die Unterstützung für Python 3.8 und niedriger einstellen. Das bedeutet, dass die minimale unterstützte Python-Version 3.9 ist.

Alias bazel/system_python.bzl entfernen

v30 wird den Legacy-Alias bazel/system_python.bzl entfernen.

Entfernen Sie direkte Verweise auf system_python.bzl zugunsten der Verwendung von protobuf_deps.bzl. Verwenden Sie python/dist/system_python.bzl, wohin es in v5.27.0 verschoben wurde, wenn Sie einen direkten Verweis benötigen.

Änderungen bei der Validierung von Feldsettern

Die Feld-Setter von Python und upb werden in v30 korrigiert, um geschlossene Enums unter Edition 2023 zu validieren. Geschlossene Enum-Felder, die mit ungültigen Werten aktualisiert werden, generieren Fehler.

Veralteten py_proto_library Makro entfernen

Das veraltete interne Bazel-Makro py_proto_library in protobuf.bzl wird in v30.x entfernt.

Dies sollte durch das offizielle py_proto_library ersetzt werden, das ab v29.x nach Protocol Buffers in bazel/py_proto_library verschoben wird. Diese Implementierung war zuvor in rules_python vor v29.x verfügbar.

Veraltete APIs entfernt

v30 wird die folgenden öffentlichen Laufzeit-APIs entfernen, die seit mindestens einer Minor- oder Major-Version als veraltet gekennzeichnet sind und veraltet oder ersetzt sind.

Reflection-Methoden

APIs: reflection.ParseMessage, reflection.MakeClass

Ersatz: message_factory.GetMessageClass()

RPC-Dienstschnittstellen

APIs: service.RpcException, service.Service, service.RpcController und service.RpcChannel

Ersatz: Ab Version 2.3.0 sollten RPC-Implementierungen nicht versuchen, darauf aufzubauen, sondern stattdessen Code-Generator-Plugins bereitstellen, die Code für die jeweilige RPC-Implementierung generieren.

MessageFactory- und SymbolDatabase-Methoden

APIs: MessageFactory.GetPrototype, MessageFactory.CreatePrototype, MessageFactory.GetMessages, SymbolDatabase.GetPrototype, SymbolDatabase.CreatePrototype und SymbolDatabase.GetMessages

Ersatz: message_factory.GetMessageClass() und message_factory.GetMessageClassesForFiles().

GetDebugString

APIs: GetDebugString

Ersatz

Kein Ersatz. Nur in Python C++, das nicht mehr veröffentlicht wird. Es wird in reinem Python oder UPB nicht unterstützt.

Änderung des setdefault-Verhaltens in Python für Map-Felder

Ab v30 wird setdefault für ScalarMap ähnlich wie für dict sein, mit der Ausnahme, dass sowohl Schlüssel als auch Wert gesetzt werden müssen. setdefault wird für MessageMaps abgelehnt.

Python verschachtelte Nachrichtenklasse qualname enthält den Namen der äußeren Nachricht

Die verschachtelte Nachrichtenklasse __qualname__ von Python enthält jetzt den Namen der äußeren Nachricht. Vor v30 hatte __qualname__ dasselbe Ergebnis wie __name__ für verschachtelte Nachrichten, da der Name der äußeren Nachricht nicht enthalten war.

Zum Beispiel

message Foo {
  message Bar {
    bool bool_field = 1;
  }
}
nested = test_pb2.Foo.Bar()
self.assertEqual('Bar', nested.__class__.__name__)
self.assertEqual('Foo.Bar', nested.__class__.__qualname__) # It was 'Bar' before

Änderungen in Objective-C

Dies wird die erste brechende Veröffentlichung für Objective-C sein.

Objective-C wird seine Hauptversion von 3.x.x auf 4.30.x anheben.

Überarbeitung der APIs zur Behandlung unbekannter Felder, die die meisten vorhandenen APIs als veraltet kennzeichnen

v30 wird GPBUnknownFieldSet als veraltet kennzeichnen und durch GPBUnknownFields ersetzen. Der neue Typ behält die Reihenfolge der unbekannten Felder aus der ursprünglichen Eingabe oder den API-Aufrufen bei, um sicherzustellen, dass jede semantische Bedeutung der Reihenfolge erhalten bleibt, wenn eine Nachricht zurückgeschrieben wird.

Als Teil davon werden auch die APIs des Typs GPBUnknownField geändert, wobei fast alle vorhandenen APIs als veraltet gekennzeichnet und neue hinzugefügt werden.

Veraltete Property-APIs

varintList
fixed32List
fixed64List
lengthDelimitedList
groupList

Veraltete Modifizierungs-APIs

addVarint
addFixed32
addFixed64
addLengthDelimited
addGroup

Veralteter Initialisierer initWithNumber:.

Neue Property-APIs

type
varint
fixed32
fixed64
lengthDelimited
group

Dieser Typ wird ein einzelnes Feldnummer in seinem Wert modellieren, anstatt *alle* Werte für eine gegebene Feldnummer zu *gruppieren*. Die APIs zum Erstellen neuer Felder sind die add*-APIs der Klasse GPBUnknownFields.

v30 wird auch -[GPBMessage unknownFields] als veraltet kennzeichnen. An seine Stelle treten neue APIs zum Extrahieren und Aktualisieren der unbekannten Felder der Nachricht.

Veraltete APIs entfernt

v30 wird die folgenden öffentlichen Laufzeit-APIs entfernen, die seit mindestens einer Minor- oder Major-Version als veraltet gekennzeichnet sind und veraltet oder ersetzt sind.

GPBFileDescriptor

API: -[GPBFileDescriptor syntax]

Ersatz: Obsolet.

Ersatz: Obsolet - Verwenden Sie GPBTextFormatForMessage(), das alle unbekannten Felder enthält.

GPBUnknownFieldSet

API: GPBUnknownFieldSet

Ersatz: GPBUnknownFields

GPBMessage unknownFields

API: GPBMessage unknownFields Property

Ersatz: -[GPBUnknownFields initFromMessage:], -[GPBMessage mergeUnknownFields:extensionRegistry:error:] und -[GPBMessage clearUnknownFields]

Veraltete Laufzeit-APIs für alten Gencode entfernen

Diese Veröffentlichung entfernt veraltete Laufzeitmethoden, die den Objective-C-Gencode von vor dem Release 3.22.x unterstützen. Die Bibliothek wird zur Laufzeit auch eine Protokollnachricht ausgeben, wenn alter generierter Code gestartet wird.

API: +[GPBFileDescriptor allocDescriptorForClass:file:fields:fieldCount:storageSize:flags:]