This is a meta-issue for tracking any breaking changes that occur before the final v2 release. Since v2 is not yet released, we reserve the right to make breaking changes to improve the API to be as good as it can be.
The CL (changelist) that introduces a breaking change will be posted here as a comment. Subscribe to this issue to be notified of breakages. We try to batch multiple breaking changes close together in time to reduce user churn.
Is there any rough idea of when api-v2 will become stable/available/recommended?
We're aspirationally aiming for GopherCon 2019, which would be the end of July. However, this is aspirational. If the v2 work is not where we would like it to be (i.e., incomplete, buggy, etc...), then we will delay. We estimate that the amount of work left is on the order of months, not years.
Breaking changes:
Minor change:
Exceedingly minor change:
Minor change:
This only affects generated code; the fix is to regenerate the .pb.go files.
Breaking change:
Breaking change:
Behavior change:
This CL enforces that the input file descriptors are well-formed according to the same rules as the C++ protoc implementation.
@dsnet Is there a new estimate on the release date of v2?
We're looking at evaluating replacing golang/protobuf over gogo/protobuf in the context of https://github.com/envoyproxy/data-plane-api (cc @htuch).
@kyessenov We don't have a solid date yet, although I'm pretty confident in saying "before the end of the year".
Unfortunately we are behind schedule on v2 release. It should occur shortly after all issues with the "blocks-v2" label are resolved. We still hope that it happens within a month or two, but should definitely happen before the end of the year.
One of the ways that we have confidence in the quality of the v2 release is that we switch most of production Go code at Google to be using the v2 implementation internally. However, this effort is taking longer than expected due to the need to support a variety of legacy and deprecated features. If you have additional questions/comments about the release process for v2, please file another issue.
Since there are a number of people subscribed to this thread, I'm locking this thread so that only updates about breaking changes are posted from here on out.
The rest of the prototype package will probably follow soon.
Breaking changes:
This CL changes the protoreflect.{Message,Enum,Extension}Type types to no longer implement the corresponding Descriptor interface. (They still have a has-a relationship with the descriptor.)
Accessing extension fields in a protoreflect.Message now requires a protoreflect.ExtensionTypeDescriptor (which implements FieldDescriptor) instead of an ExtensionType (which doesn't any more). ExtensionType.Descriptor returns an ExtensionTypeDescriptor.
The prototype package is removed as unnecessary.
Breaking change:
The protoiface.ExtensionDescV1 type is removed. (And lots of other internal refactoring, but I believe that's the only breaking API change.) This is unlikely to affect anyone.
Minor breaking change:
Breaking change:
This is a fiddly change, but improves clarity a bit around the very subtle interactions between the various views of an extension.
Breaking change:
Superseded by the more general-purpose Message.NewField, List.NewElement, and Map.NewValue.
Breaking change:
Removed to simplify the interface, and because there are now better ways to do just about everything they were used for.
Minor breaking change:
m.Has(extensionTypeDescriptor) will now return false for a zero-length repeated extension field.
Breaking change:
The (*Files).Register and (*Types).Register functions in the protoregistry package have been replaced by type-safe Register{File,Enum,Message,Extension} methods.
The protoregistry.NewFiles and protoregistry.NewTypes functions are gone. (Just call Register...)
The protoregistry.Type type is removed (nothing references it any more).
Minor breaking change:
Minor addition to some protoreflect types, only affecting implementations of those types.
Brought reflection behavior for empty lists and maps in line with documentation. Technically not a breaking change (just doing what the documentation said!), but it would have been easy to depend on the previous behavior by accident.
Changes to the fast-path ProtoUnmarshal method: It moves into the protoreflect.Message interface, and the method signature changes a bit.
Performance improvement (avoids an interface->interface type conversion, which is expensive) and future-proofing.
Shallow merges were well-defined, but we're debating whether that definition is useful. Dropped support for shallow merges for now, since this isn't a v1 feature we need to preserve.
Convenience methods on protoreflect's List and Map types.
One last change to the fast-path method signatures, for consistency and future expansion.
APIv2 is released. No more breaking changes!
Most helpful comment
We're aspirationally aiming for GopherCon 2019, which would be the end of July. However, this is aspirational. If the v2 work is not where we would like it to be (i.e., incomplete, buggy, etc...), then we will delay. We estimate that the amount of work left is on the order of months, not years.