This weeks release has been tagged as

    ffb4f241773cb9d9351bfa8f4f19f39d97019e9d

== Release Notes

=== Breaking Changes

None

=== New Features

* The replication v3 logic now evaluates the tracking configurations from the
  v2 tracking API.

=== Improvements

* The introduction of the git-ref-format crate into various other crates
  in the codebase makes our handling of ref strings more consistent and
  type-safe™

=== Other

* The LICENSE no longer contains any linking exceptions and the
  copyright is held by 'The Radicle Link Contributors' rather than 'The
  Radicle Foundation'

=== Notes

We are currently aware of a problem when enabling the `replication-v3`
flag. This flag pulls in `get-tempfile` v1.0.6 which unfortunately
installs some signal handlers. This means that applications which enable
`replication-v3` may find their own signal handlers are affected. We are
working on a solution to this but in the meantime the workaround is to
depend on `git-tempfile:1.0.6` and disable it's signal handlers with the
following

    git_tempfile::force_setup(git_tempfile::SignalHandlerMode::None);

=== Shortlog

Alex Good (9):
      Update git-pack to 0.14.0
      Update the p2p node RFC

Jason Yundt (3):
      Sync LICENSE file with Radicle Upstream
      Clarify copyright situation
      Remove Radicle Linking Exception

Kim Altintop (11):
      git-ext: conversions and check from git-ref-format
      link-crypto: conversion of `PeerId` to git-ref-format
      link-identities: conversion of `Urn` to git-ref-format
      tracking: use git-ref-format
      git-ref-format: const `Component`s
      git-ref-format: `Extend` for `RefString`
      git-ref-format: infallible constructor for `Qualified`
      git-ref-format-macro: fix import
      link-tracking: evaluate config against ref
      test: remove and ignore proptest-regressions
      Revert "test: use gitoxide for link-git-protocol tests"

> * The replication v3 logic now evaluates the tracking configurations from the
>   v2 tracking API.

Some doubts arose about this [0]. Specifically, partial filtering of
collaborative objects does not seem sound to apply on the replication level.
We'll go for a simpler yes/no model, where "no" means only refs needed for
identity verification are replicated.

[0]: https://lists.sr.ht/~radicle-link/dev/%3C20220218140926.GC36711%40schmidt.localdomain%3E