Rename cbor feature branch dep for downstream compatability

[SophisticaSean]

Description

Atree depends on a feature branch version of cbor feature/stream, unfortunately other dependencies are using the master/main branch release version of cbor. If these come into contact in a repo there's no way around the dep mismatch. This renames the import of the pinned feature-branch version of cbor to cborstream so that downstream deps can still use the most recent cbor without conflict.

---

• Targeted PR against main branch
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work
• Code follows the standards mentioned here
• Updated relevant documentation
• Re-reviewed Files changed in the Github PR explorer
• Added appropriate labels

[SophisticaSean]

nvm this won't work. we need to have a separate fork of feature/stream in order for downstream deps to not get clobbered by the feature version of cbor

[fxamacker]

@SophisticaSean Thanks for opening this PR.

I tried this approach during our conversation on Slack and it will break existing projects using atree (onflow projects as well as external projects).

As mentioned on Slack, I can update fxamacker/cbor's feature/stream-mode branch to be a superset of v2.7.0.

So go.mod can use something like:
github.com/fxamacker/cbor/v2 v2.7.1-0.20250345678901-123456789012

Since v2.7.1-2025... would be a 100% compatible superset of v2.7.0 with higher version number, I think it might work without breaking existing projects using atree.

Let's try the non-breaking approach first and see if it works. If it doesn't work, we still benefit by having cbor feature/stream-mode updated to cbor v2.7.0 for this PR to use.

[SophisticaSean]

@SophisticaSean Thanks for opening this PR.

I tried this approach during our conversation on Slack and it will break existing projects using atree (onflow projects as well as external projects).

As mentioned on Slack, I can update fxamacker/cbor's feature/stream-mode branch to be a superset of v2.7.0.

So go.mod can use something like: github.com/fxamacker/cbor/v2 v2.7.1-0.20250345678901-123456789012

Since v2.7.1-2025... would be a 100% compatible superset of v2.7.0 with higher version number, I think it might work without breaking existing projects using atree.

Let's try the non-breaking approach first and see if it works. If it doesn't work, we still benefit by having cbor feature/stream-mode updated to cbor v2.7.0 for this PR to use.

Definitely agree. I've tried a couple ways to work around this to no avail. I'll close this for now, but even with a superset of features, since go.mod replace directives dont work for dependencies, even a superset of features will still collide on differing cbor versions.