forked from solana-labs/solana
-
Notifications
You must be signed in to change notification settings - Fork 636
Refactor - Makes loader-v4 the default #2796
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the late flyby review, but disabling new deployments on the old loader needs to be done through a separate feature in a future release.
We can't expect all tooling to immediately switch over to loader-v4 as soon as it's available. There needs to be some amount time where both loaders are available for new deployments while people upgrade, same as we did when the upgradeable loader was added. This could be at least 1 minor release, but 3 minor releases (~1 year) would likely be ideal.
cc @nickfrosty for his thoughts, since he's been looking at the associated SIMD solana-foundation/solana-improvement-documents#167
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good point. cc @Lichtso
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, that is why we only disable new deployments. All existing programs can be still be redeployed etc. under loader-v3. There is no point in turning on loader-v4 if we do not deprecate loader-v3, because getting rid of loader-v3 is the entire point. Also, keep in mind that tooling can be tested against the new loader on testnet and devnet, if that is the concern.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The main point is that we can't immediately break users, especially when they're typically slow to adopt new releases.
Take the anchor deploy code for example: https://github.com/coral-xyz/anchor/blob/2b0f3a7c999771f40e240b3ce421895ce6b066cf/cli/src/lib.rs#L3874 -- they're relying on calling
solana program deploy
.If they wanted to avoid breaking immediately, they would need logic to check the feature gate status, conditionally call
program-v4
instead ofprogram
, and force everybody to upgrade to the newest version of the CLI using that code, all before the feature gate is enabled. It isn't reasonable to expect people to make changes and force adoption of new tools so quickly.We didn't break people immediately when loader-v3 was added, and we had a fraction of developers at the time. We can't immediately break them here. I'm happy to come up with an alternative roll out plan together.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could do the feature gate checking in our CLI and alias
program
deploy toprogram-v4
deploy.What I am saying is that the day that people start deploying to loader-v4 will not be the day it becomes available, but the day the old one stops working. And that day will be breaking users independently of whether the new loader is available before or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That plan still requires people to update to the newest tools immediately, which is neither reasonable nor a good developer experience.
And I'm not sure I agree with you -- for example, if we alias
program
toprogram-v4
as you suggest, then people will automatically start using loader-v4 as they adopt the new tools without realizing it.Then, after some time, we can put out a big loud message that
solana program deploy
will start failing if you're using any version before 2.2, give people 3-6 months to upgrade, and then disable new deployments. That way, only people who haven't upgraded their tools in a long time will be broken, which should be a small amount of people, and we can point to the loud message that we put out months ago.Either way, this change needs to come with a thoughtful rollout strategy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, I will add another feature gate. This however would mean there are four phases:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Beautiful, thanks!
We can save it for the future, but I'll need to understand more about what "force migration" looks like, since that could potentially break tools like DAOs which rely on using loader-v3 instructions for program management. And we should start signaling this whole process as soon as possible to devrel.