fix: 0.50 pin libp2p-quic prerelease deps

[ozwaldorf]

Description

backport of #3548, and should fully resolve #3537

Notes

• libp2p-quic bumped to -alpha.0
  • pinned libp2p-tls -alpha
• bumped libp2p to 0.50.2
  • bumped to new libp2p-quic version

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• A changelog entry has been made in the appropriate crates

[thomaseizinger]

It is released without the 0 so I think we can't just change that now?

[ozwaldorf]

Hmm, would cargo publish actually reject this version? the next version (and latest) is -alpha.2, does it have a check to ensure the prerelease number is incremental? afaik, since it's still unique it'd work. Also just tried a cargo publish --dry-run and it seems to pass at least on that side of things

[thomaseizinger]

What is the upside of publishing a new version?

[ozwaldorf]

We need a version of libp2p-quic to depend on from libp2p 0.50 that has libp2p-tls pinned, so that it wont pull [email protected] anymore but instead correctly use tls@-alpha (which is still causing libp2p 0.50.1 to break)

Also see the comment from @mxinden #3548 (comment)

Since a later version of quic has already been released, to avoid mixing up the versions i used alpha.0 for the version to retain some ordering but still have a unique one to pin libp2p against

[thomaseizinger]

Ah yes, you are completely right. I forgot about the dependency from libp2p-quic to libp2p-tls.

[ozwaldorf]

Any updates here?

[thomaseizinger]

I still need to verify that we can actually release this. @mxinden do you know?

[thomaseizinger]

Do you actually need this to fix a problem where you can't just keep the version pinned in Cargo.lock? Would updating to v0.51 be an option for you?

[ozwaldorf]

Do you actually need this to fix a problem where you can't just keep the version pinned in Cargo.lock? Would updating to v0.51 be an option for you?

We aren't currently pushing locks atm. To temporarily fix things on our end, we're now using a patch with the git rev for 0.50.1, which works since it loads all deps from that commit and ignores the crate releases. We are planning to update to 0.51 as well, although it'll take some time as migration was not as easy as initially expected.

[thomaseizinger]

Okay thanks for that.

Feel free to tag us in any update PRs if you have questions!

cc @mxinden The update to 0.51 seems to be more difficult than expected so I think it is worth trying to resolve this.

[thomaseizinger]

I am proposing a different strategy on how to handle this: #3580.

[thomaseizinger]

Closing this as a wont-fix (for the v0.50 version in particular). Please upgrade to v0.51 if you can. Feel free to tag us in PRs if you need help.

#3580 should prevent this in the future.