Solana 2.0.0 breaks a lot of things

[cryptopapi997]

I wrote a twitter thread about this explaining the issue, but wanted to open it here too to get people's takes on what's the best way forward. Solana 2.0.0 just dropped with a bunch of breaking changes, and a good number of spl programs restrict their solana version using <= 2.0.0 rather than <2.0.0 (e.g. https://github.com/solana-labs/solana-program-library/blob/master/token/program/Cargo.toml#L21). This means that these resolve to 2.0.0 where other dependencies resolve to 1.18.17 as they should, meaning a lot of things break.

One solution is to switch all dependencies with this from 3.0.2 to 1.0.1 (or whichever the last release was when these dependencies used <) but this probably breaks a bunch of other things. Another is to make anchor use 2.0.0, but this isn't a good solution for obvious reasons, as this means anchor programs won't be deployable until 2.0.0 hits mainnet. Last thing I can think of would be for Solana to release e.g. 3.0.3 which has < and 4.0.0 which has =, and anchor using 3.0.3, but this isn't likely either.

Would love to get your thoughts on this @acheroncrypto

[acheroncrypto]

Hey, thanks for creating the issue.

Having SemVer incompatible versions of the same package can lead to type incompatibilities since they are treated as different types, as also mentioned in solana-labs/solana-program-library#6182.

We would also need to have the same requirements as SPL to make this work by default, which makes v2 completely pointless.

In the meantime, the easiest solution is to downgrade Solana dependencies to 1.18.17 by either manually editing the lock file, or simply running:

cargo update -p [email protected] --precise 1.18.17

[cryptopapi997]

Sounds good. Do you know what the path forward here looks like? Upgrade everything in anchor? Or should Anza/Labs release another spl version (that doesn't depend on 2.0.0) to address this?

[acheroncrypto]

I don't know how many other crates broke because of this, but Anchor is certainly not the only one. If we upgrade, then everybody else also needs to upgrade (recursively), which is what v2 should have aimed to solve (solana-labs/solana#32503).

On the other hand, Solana and SPL repos have a circular dependency issue, making it difficult for Solana crates to bump breaking versions.

I think the best solution would be for SPL crates to publish a patch release to revert solana-labs/solana-program-library#6182 and upgrade SPL crates to v2 (only v2) with a major release that Solana v2 crates should depend on. This way, however many downstream projects that broke because of this don't need to do anything.

While this solution is also not perfect, as it would result in type incompatibilities due to various dependencies depending on different versions of Solana crates, it's still much better than breaking existing crates that worked perfectly fine before v2 was out.

[DemidovVladimir]

Use spl-transfer-hook-interface v0.6.3
And cargo update -p [email protected] --precise 1.18.17

[cryptopapi997]

Seems to be fixed now with the release of solana 2.0.2! 🥳