Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump github.com/multiformats/go-multiaddr from 0.14.0 to 0.15.0 #180

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

dependabot[bot]
Copy link
Contributor

@dependabot dependabot bot commented on behalf of github Feb 25, 2025

Bumps github.com/multiformats/go-multiaddr from 0.14.0 to 0.15.0.

Release notes

Sourced from github.com/multiformats/go-multiaddr's releases.

v0.15.0

Breaking Changes

  • There is no Multiaddr interface type.
  • Multiaddr is now a concrete type of []Component. Not an interface.
  • Empty Multiaddrs should be checked len(ma) == 0, exactly how slices should be checked with len(s) == 0 rather than s == nil.
  • Components do not implement Multiaddr as there is no Multiaddr to implement. The do implement a Multiaddrer interface that lets them convert to Multiaddrs.
  • Multiaddr can no longer be a key in a Map. If you want unique Multiaddrs, use string(Multiaddr.Bytes()) or Multiaddr.String() as the key, otherwise you can use the pointer value *Multiaddr.

Why?

This library has had multiple issues related to Multiaddr being an interface. Many methods use and return nil as the zero value, which behaves poorly when the user forgets to do a nil check on every returned value and attempts to call a method on the nil pointer. For example, using Split to split a Multiaddr and then using Join to rebuild the original Multiaddr historically would panic in case one side of the split was nil. Using an interface also leads to incorrect usages of == to check if two Multiaddrs were equal (would only work for pointer equality) and, likewise, incorrectly using Multiaddr as a key for a map.

Using an interface is typically done to provide a consistent API surface for multiple implementing types. In practice however, the Multiaddr interface was only implemented for multiaddr and component (with arguably some awkwardness when using a component as a Multiaddr).

The better approach is to use a concrete type for a Multiaddr. This lets pointer receiver methods work even if the pointer is nil, since the compiler already knows which function to call. Most methods now take a value rather than a pointer which avoids the issue of a nil pointer dereference completely.

What's changed

v0.15 refactors the codebase to make it much harder to hit nil pointer dereference panics.

It does so by taking a different approach to how we've treated multiaddrs in the past. Instead of attempting to make them a general datastructure, we focus on treating them as just an encoding scheme. Users of multiaddrs are expected to parse the multiaddr into some struct that is suitable for their use case, and use the multiaddr form when interoperating. By treating Multiaddrs as just an encoding scheme we can make a number of simplifications in the codebase. Specifically we now:

  • Remove the Multiaddr interface.
  • Make Multiaddr a concrete type of []Component

Migration

Refer to ./v015-MIGRATION.md for breaking changes and migration tips

Full Changelog: multiformats/go-multiaddr@v0.14.0...v0.15.0

Commits
  • 30b45fb chore: release v0.15.0 (#266)
  • 4d1f355 refactor: Backwards compatible Encapsulate/Decapsulate/Join/NewComponent (#272)
  • 2ac523b refactor: keep same api as v0.14.0 for SplitFirst/SplitLast (#271)
  • 4abf520 Merge pull request #268 from multiformats/uci/update-go
  • e41d519 chore!: bump go.mod to Go 1.23 and run go fix
  • 46805b0 refactor: Follows up on #261 (#264)
  • 1ef63b5 refactor!: make the API harder to misuse (#261)
  • d19cf5d build(deps): bump golang.org/x/crypto from 0.18.0 to 0.31.0 (#259)
  • See full diff in compare view

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Bumps [github.com/multiformats/go-multiaddr](https://github.com/multiformats/go-multiaddr) from 0.14.0 to 0.15.0.
- [Release notes](https://github.com/multiformats/go-multiaddr/releases)
- [Commits](multiformats/go-multiaddr@v0.14.0...v0.15.0)

---
updated-dependencies:
- dependency-name: github.com/multiformats/go-multiaddr
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <[email protected]>
@dependabot dependabot bot added the chore Simple updates or version bumps label Feb 25, 2025
@dependabot dependabot bot requested a review from galt-tr February 25, 2025 15:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore Simple updates or version bumps
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant