Versioned releases incl. publishing of crates on crates.io

[shazow]

Component

Forge, Cast, Anvil

Describe the feature you would like

Foundry needs to start tagging versioned releases, and providing permanent release assets.

Ideally a v1.0 version would be great.

Until then, even a v0.x release set would be a useful starting point, especially for third-party packaging of foundry.

Additional context

Previous: #3881

This issue is to allow people to track and subscribe to this topic.

[rkrasiuk]

@gakonst thoughts?

[gakonst]

Yeah we've already announced 0.2 but didn't tag it proper I think. Let's do a v0.3 release and have persistent binaries for it as well as allow them to be downloaded in the action.

I think we'll need to finally figure out our release culture / cadence and changelogs...

[3ldarin]

We use Foundry at my work, and I wanted to write a Homebrew formula for it for a few reasons:

• curl | bash-ing a script off the internet is not very safe, and we all know how much of a target people who work in crypto are.
• Putting this in homebrew will encourage people to upgrade foundry regularly, as they upgrade everything else they have in Homebrew.
• People who are installing foundry for the first time and people who are upgrading will be on the same version, whereas right now they'll get differently nightly versions if they. This adds another small friction point when trying to debug issues together.

However, I was forced to put it in a Homebrew tap instead of Homebrew Core because Foundry is not properly versioned.

If it would be helpful, I'm happy to help you guys set up some release documentation (and possibly tooling if needed) around this.

[3ldarin]

For now, you can install foundry via homebrew with brew install 3ldarin/taps/foundry.

[gakonst]

(cc @onbjerg this might be a small one given you easily did the reth formula)

[onbjerg]

@gakonst we already have a foundry formula it's just borked because we don't have actual versions yet

[3ldarin]

@gakonst @onbjerg I pinned it to commit hashes in mine, but I have no idea which commits are ready for release vs which aren't.

[RensR]

Just having a more recent version that isn't pruned would help. We ran nightly for a long time but that changes things too often without warning so we had to fall back to a stable version. The latest non-pruned version is Nightly (2023-08-02), which is almost 2 months behind. Can we get a new version that won't be pruned? Ideally with some tag indicating that it will remain available and some schedule when new non-pruned versions will be released.

[RensR]

@gakonst is it by design that the unofficial long term supported released (the ones on the 2nd of each month that stay up) change hashes randomly? Not sure how or why, but we relied on the Oct 2nd release, which is still up, with hash e0722a10b45859892ec3b998df958a9edc77c202. Not when I go to that release it is the same but targets hash5be158ba6dc7c798a6f032026fe60fc01686b33b.

Is there any way, before the proper versioning starts, to use Foundry with static versions?

[gakonst]

Had not realized this. Do you mind opening a separate issue to discuss that, we'll investigate, just don't want to miss track

[3ldarin]

(@RensR would you mind cc'ing me on that, if it's not too much trouble?)

[excalq]

Interested to hear when this may happen, as not having versioned or immutable tags makes team-wide devops quite challenging. Specifically when encountering breaking changes when each developer has run foundryup causing them to have different versions. This also makes CI/CD brittle. It would be a big improvement to have v0.x semantic versioning over the current mutable nightly tagging.

[RensR]

@excalq FYI we've solved it with a makefile that installs a specific version. Devs never run foundryup, and CI is locked to the same version as the makefile. Not perfect but it works pretty well.

[zerosnacks]

Related: #8659, request is to make the verify crate available as standalone lib and to publish it to crates.io