`2.0.0` `solana-program` release causing issues due to `<=2.0.0` on patch upgrades.

[jacobcreech]

Problem

solana-program upgraded to 2.0.0 on Friday, leading to a number of builds across the ecosystem because of the <=2.0.0 in a patch version upgrade on #6182.

The problematic dependencies are as follows:

spl-pod version 0.1.1 -> Previous version 0.1.0 did not have <=2.0.0. Upgrade on patch broke some builds
spl-token-metadata-interface version 0.2.1 -> Previous version 0.2.0 did not have <=2.0.0. Upgrade on patch broke some builds
spl-associated-token-account version 2.3.1 -> Previous version 2.3.0 did not have <=2.0.0.
spl-token version 4.0.1 -> Previous version 4.0.0 did not have <=2.0.0.
spl-token-group-interface version 0.1.1 -> Previous version 0.1.0 did not have <=2.0.0.

These are the ones I can find at this time. This affects anyone using anchor-spl right now, as well as some projects that don't use Anchor but pull in spl-token 4.0.1 while using solana-program 1.X.

Relevant Anchor issue: solana-foundation/anchor#3044

Suggested Solution

Purge the versions causing problems, re-release them without the <=2.0.0, upgrade and release with <=2.0.0 as a "major" version if not already available. As mentioned here

[joncinque]

I ran into a lot of these issues while publishing the last spl-token-cli, so there are compatible major versions that already exist in spl:

• spl-associated-token-account -- v3 exists, so we can yank 2.3.1
• spl-token -- might need v5, then we can yank 4.0.1
• spl-token-group-interface -- v0.2 exists, so we can yank 0.1.1
• spl-token-metdata-interface -- v0.3 exists, so we can yank 0.2.1
• spl-pod -- v0.2 exists, so we can yank 0.1.1
• spl-token-2022 -- is ok

There are some more:

• spl-program-error -- yank 0.3.1
• spl-discriminator -- yank 0.1.1
• spl-type-length-value -- yank v0.3.1
• spl-tlv-account-resolution -- yank v0.5.2
• spl-transfer-hook-interface -- yank v0.5.1

With that, I think everything will be ok -- if people use the newest versions, they'll still get the version that allows for both, so they'll need to be careful with dependencies, but at least the patch version won't automatically pick it up

[joncinque]

But first, we'll need to update the monorepo to the correct versions

[joncinque]

Thankfully, it looks like just spl-token needs an update 🥳

[joncinque]

Bah, never mind, it unfortunately creates more downstream issues due to the version mismatches for the new spl-token major versions.

The real solution will be a lot like the proposed solution:

• upgrade SPL to v2
• publish all new major versions for SPL crates
• get agave to use these new crates + backport
• yank the old ones

[jacobcreech]

Don't you want to republish the old versions as well without the <=2.0.0 to avoid breaking any build that uses them? Otherwise you'll break more than just the monorepo

[joncinque]

Sorry, I don't think I understand -- shouldn't the existing pre-patch versions without the <= 2.0.0 be fine? Here's the proposal:

• yank the patch versions with <= 2.0.0, people can use the old ones
• keep new major version with <= 2.0.0 (all spl crates have one of these currently)
• publish a new major version with only 2.0.0 support

[willhickey]

Using spl-token as an example. The relevant published versions are:
v4.0.0 -> ^1.16.1
v4.0.1 -> >=1.17.17, <=2
v5.0.0 -> >=1.18.11, <=2

I think the correct remediation is:

• create a new token-v4.0 branch just before the v5.0 version bump
  • on the v4.0 branch remove <=2 monorepo dependencies
  • publish v4.0.2
• On master bump the version to 6.0.0 and remove >=1.18.11 from monorepo dependencies
• Yank v5.0.0
• Publish v6.0.0 from the updated master
• Update monorepo master and v2.0 with spl-token = "6"
• Publish new v2.0.x crates from the monorepo
• yank v4.0.1

Which would give us this:
v4.0.0 -> ^1.16.1
v4.0.1 -> >=1.17.17, <=2 yanked
v4.0.2 -> >=1.17.17
v5.0.0 -> >=1.18.11, <=2
v6.0.0 -> 2

Hopefully we won't have to do much with the new branches (for all the old major versions) but without them we don't have a way to publish new patches to replace the yanked versions.

I think this is consistent with Jacob & Jon's proposals above. Any thoughts on this plan before I start yanking crates?

[joncinque]

I'm almost onboard, but my main question: why do we need 4.0.2?

Also, we can't yank 4.0.1 until the monorepo is updated and backported since it requires =4.0.1. https://github.com/anza-xyz/agave/blob/69c0b0edb6fa5ac17c2e15ef19c9b0487d105352/Cargo.toml#L418

My plan is to leave a major version that allows both, like v5.0.0, but then have v6.0.0 which only allows 2

Edit: oh, and we won't be able to update the monorepo to 4.0.0, 4.0.2, or 5.0.0 😅 which is why I think we need to bite the bullet and upgrade all of the spl crates to v2 only and then update the monorepo to those

[willhickey]

Oh yeah, good point about needing a new major to remove the monorepo dependency.

Maybe we don't need 4.0.2. My thinking was we don't really support v1.16 or v1.17 on public clusters anymore, so I don't want people using 4.0.0. But hopefully projects that use 4.0.0 don't have monorepo dependencies pinned and will pick up v1.18 by default. I guess if anyone is pinned to v1.16 that can be their problem.

I'll update my comment above shortly

[jacobcreech]

Sorry, I don't think I understand -- shouldn't the existing pre-patch versions without the <= 2.0.0 be fine?

I was worried someone was pinning =4.0.1 or one of the other offending patch versions and then their build will start failing. Looking at crates.io dependents though, looks like we should be fine.

[jacobcreech]

Also, we can't yank 4.0.1 until the monorepo is updated and backported since it requires =4.0.1. https://github.com/anza-xyz/agave/blob/69c0b0edb6fa5ac17c2e15ef19c9b0487d105352/Cargo.toml#L418

If you were to republish without the <=2.0.0 after yanking, you wouldn't run into this issue. I'm worried some dependent of 4.0.1 will start to fail post our yanking other than the monorepo.

[willhickey]

If you were to republish without the <=2.0.0 after yanking, you wouldn't run into this issue. I'm worried some dependent of 4.0.1 will start to fail post our yanking other than the monorepo.

We can publish new patch versions (eg 4.0.2) but I don't want to re-publish yanked versions with changes. Too much opportunity for confusion