fix(deps): update all deps #16
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "renovate/all"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR contains the following updates:
v1.4.3
->v1.5.1
v1.25.0
->v1.26.0
Release Notes
golang/protobuf
v1.5.1
Compare Source
Notable changes:
v1.5.0
Compare Source
Overview
This marks the
ptypes
package as deprecated and upgrades the dependency ongoogle.golang.org/protobuf
to a pre-release version of v1.26.0. A subsequent patch release will update the dependency to v1.26.0 proper.Notable changes
protocolbuffers/protobuf-go
v1.26.0
Compare Source
Overview
This release reduces dependencies on other modules, enforces strict behavior with generated Go packages and name conflicts, expands support for aberrant message types, and provides minor new features in protobuf reflection.
Notable changes
New features:
Behavior changes:
Bug fixes:
Performance optimizations:
Reduced dependencies
Go code generated by
protoc-gen-go
no longer have a hard dependency on thegithub.com/golang/protobuf
module. In previous releases, the generator would emit a reference to theProtoPackageIsVersion4
constant to statically enforce that a sufficiently new version of the older module was being linked in. In the last year, most of the Go ecosystem has moved to Go modules, where we can rely on Go modules to enforce a minimum version constraint on the older protobuf module. While there continues to be a cyclic dependency between thegithub.com/golang/protobuf
andgoogle.golang.org/protobuf
modules, the cyclic dependency was briefly broken and re-added to clear out the infinitely growing list ofgo.sum
entries.The module dependency on the
google.golang.org/genproto
module has been removed. Any program that depends on bothgoogle.golang.org/protobuf
andgoogle.golang.org/genproto
must use at least versioncb27e3aa
from May 26th, 2020. There is a runtime check at program initialization that panics when too old of a version of thegenproto
module is being linked into the binary.The well-known types provided by this module are built from v3.15.3 of the protobuf toolchain.
Require Go import path
As mentioned in the v1.20.0 release from March 2nd, 2020, the Go generator will require that the Go import path be specified for all
.proto
files being generated and their transitive dependencies. Since v1.20.0, every occurrence of a.proto
file missing a Go import path has resulted in a warning being printed to standard error that this will eventually become a fatal error. The Go import path is normally specified by declaring ago_package
option in the.proto
file. Alternatively, this can be specified at compile-time with aM
flag passed on the command line. See the developer documentation for more information on thego_package
option andM
flag.Fatal namespace conflicts
As mentioned in the v1.20.0 release from March 2nd, 2020, the Go protobuf runtime will fatally fail if it detects the registration of duplicate names. Since v1.20.0, every occurrence of a conflict has resulted in a warning being printed to standard error that this will eventually become a fatal error. See the developer documentation for more information about what a namespace conflict is and how to resolve it.
While it is preferable that the source of the conflict be fixed, the fatal error can be immediately worked around in one of two ways:
1. At compile time. The default behavior for handling conflicts can be specified at compile time with a linker-initialized variable:
At program execution. The behavior for handling conflicts when executing a particular Go binary can be set with an environment variable:
GOLANG_PROTOBUF_REGISTRATION_CONFLICT=warn ./main
This will cause the runtime to use the conflict handling behavior from v1.25.0 and earlier, which is to simply warn about them.
Support for aberrant message types
This project's compatibility document specifies that we only guarantee runtime compatibility with messages generated by
protoc-gen-go
. Use of this module's runtime with any other custom message type will have mixed results, ranging from panics, to unspecified behavior, to working correctly. The proper way for custom message types to perfectly work with this module is for the custom type to implement theprotoreflect.ProtoMessage
interface, which allows a given message implementation to self-describe how its contents should be introspected.Since some widely depended upon modules have custom message types not generated by
protoc-gen-go
, we expand support in this module's runtime to be able to handle those aberrant message types. This change should reduce the probability that using one of those modules with this module results in a panic and instead have reasonably correct behavior.This support is not covered by this project's compatibility guarantee and may be modified or removed in a future version of this module without notice. Custom types must move to supporting protobuf reflection to ensure long-term compatibility.
Upcoming breakage changes
This release makes some potentially disruptive changes that have been announced since the v1.20.0 release on March 2nd, 2020. Not all breaking changes mentioned in the v1.20.0 have been made and may still take effect in a later version of this module.
There are no new upcoming breaking changes to announce in this release.
Renovate configuration
📅 Schedule: At any time (no schedule defined).
🚦 Automerge: Enabled.
♻️ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR has been generated by WhiteSource Renovate. View repository job log here.