Skip to content
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

feat(v1): Migration guide #922

Open
wants to merge 28 commits into
base: master
Choose a base branch
from
Open

feat(v1): Migration guide #922

wants to merge 28 commits into from

Conversation

Evalir
Copy link
Member

@Evalir Evalir commented Jun 16, 2023

This PR contains the migration guide for V1. It contains:

  • A guide on how to upgrade foundry locally to V1
  • A list of deprecated features
  • A list of non-breaking changes that are important to know
  • A list of breaking changes, and how to tackle them
  • Recommended tips for managing the migration.

I expect to flesh out more content on this over the next few days to make it more thorough, but I believe this draft covers enough for us to start discussing.

cc @mds1 for feedback!

@Evalir Evalir marked this pull request as draft June 16, 2023 04:48
@cloudflare-workers-and-pages
Copy link

cloudflare-workers-and-pages bot commented Jun 16, 2023

Deploying with  Cloudflare Pages  Cloudflare Pages

Latest commit: 9f67b28
Status: ✅  Deploy successful!
Preview URL: https://b28b529b.foundry-book.pages.dev
Branch Preview URL: https://evalir-migration-guide.foundry-book.pages.dev

View logs

Copy link
Member Author

@Evalir Evalir left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a small self-review

note that i haven't done a grammar check on this yet. will do so tomorrow

src/getting-started/migrating-to-v1.md Outdated Show resolved Hide resolved
src/getting-started/migrating-to-v1.md Outdated Show resolved Hide resolved
src/getting-started/migrating-to-v1.md Outdated Show resolved Hide resolved
@Evalir Evalir changed the title [DO NOT MERGE] feat(v1): Migration guide feat(v1): Migration guide Jun 27, 2023
@Evalir Evalir marked this pull request as ready for review June 27, 2023 14:28
Copy link
Contributor

@mds1 mds1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Didn't finish reviewing yet but here's the first batch of comments. Really great overall so far though, will finish giving this a read tomorrow

src/migrating-to-v1/breaking-changes.md Outdated Show resolved Hide resolved
src/migrating-to-v1/breaking-changes.md Outdated Show resolved Hide resolved
src/migrating-to-v1/breaking-changes.md Outdated Show resolved Hide resolved
src/migrating-to-v1/breaking-changes.md Outdated Show resolved Hide resolved
src/migrating-to-v1/breaking-changes.md Outdated Show resolved Hide resolved
src/migrating-to-v1/breaking-changes.md Outdated Show resolved Hide resolved
src/migrating-to-v1/breaking-changes.md Show resolved Hide resolved
src/migrating-to-v1/breaking-changes.md Show resolved Hide resolved
src/migrating-to-v1/breaking-changes.md Show resolved Hide resolved
src/migrating-to-v1/breaking-changes.md Outdated Show resolved Hide resolved
src/migrating-to-v1/breaking-changes.md Outdated Show resolved Hide resolved
src/migrating-to-v1/breaking-changes.md Show resolved Hide resolved
src/migrating-to-v1/breaking-changes.md Outdated Show resolved Hide resolved
src/migrating-to-v1/breaking-changes.md Outdated Show resolved Hide resolved
src/migrating-to-v1/migrating-to-v1.md Outdated Show resolved Hide resolved
src/migrating-to-v1/non-breaking-changes.md Outdated Show resolved Hide resolved
src/migrating-to-v1/non-breaking-changes.md Outdated Show resolved Hide resolved
src/migrating-to-v1/upgrading-to-v1.md Show resolved Hide resolved

### Upgrading your CI

When it comes to CI, you can add a `version` input field with `v1.0.0` or your desired stable release. This will pin the CI to that stable version.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this support ways to specify a range of versions, e.g. v1 to always use the latest v1.x.y release? we definitely should support something like that, which is common for github actions

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, not really—but we could add this and release a new CI toolchain version.

Co-authored-by: Matt Solomon <matt@mattsolomon.dev>
src/migrating-to-v1/breaking-changes.md Show resolved Hide resolved
src/migrating-to-v1/breaking-changes.md Show resolved Hide resolved
src/migrating-to-v1/breaking-changes.md Outdated Show resolved Hide resolved
src/migrating-to-v1/deprecated-features.md Outdated Show resolved Hide resolved
src/migrating-to-v1/deprecated-features.md Outdated Show resolved Hide resolved
src/migrating-to-v1/deprecated-features.md Outdated Show resolved Hide resolved
src/migrating-to-v1/deprecated-features.md Outdated Show resolved Hide resolved
src/migrating-to-v1/migrating-to-v1.md Outdated Show resolved Hide resolved
- Snapshot failures between fuzz runs [are now persisted](https://github.com/foundry-rs/foundry/pull/4974), so workarounds are not needed anymore when testing fuzz runs that use snapshots.
- Sensitive broadcast logs are now logged into the `.gitignore`d `cache` directory, instead of being included in the broadcast files that are intended to be committed.
- The base fee calculation on Anvil is now entirely skipped if the fee is set to 0.
- `vm.startPrank` now overwrites the existing prank instead of just erroring. However, the already set prank must be used first.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

However, the already set prank must be used first. this sentence wasn't immediately clear to me, what does this mean?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I believe this might be an undocumented, somewhat recent change on startPrank—when this overwrite change was made, i believe the rule is now that if the prank has not been used, it will error. if it has been used, it will overwrite the existing prank.

so essentially before overwriting the prank you need to use it first

curl -L https://foundry.paradigm.xyz | bash
```

This will reinstall `foundryup`. You can then run `foundryup` on your terminal to download the latest `V1` version.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should standardize V1, V1 and v1. I'm indifferent as to which but should be the same across the docs.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. My pick is v1—but wdyt @gakonst ? needs to align with blog post.

@thedavidmeister
Copy link

please reconsider the changes to expectRevert being unable to test reverts behind a jump

or provide some functionality that allows me to specify the depth, if the intent is to be more strict i'm happy to be more explicit

@zerosnacks zerosnacks self-assigned this Sep 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants