I’d love to propose we maintain a community-driven “StarkNet Tooling Matrix”—a simple table mapping each StarkNet release to the exact versions of our core dev tools (Scarb, starknet-cli, explorers, IDE plugins, etc.).
Why?
Avoid version mismatches and broken builds
Speed up onboarding and reduce support questions
Help teams coordinate upgrades proactively
How it could work:
A GitHub repo with a Markdown table
Anyone can submit a PR when a new StarkNet / tool release happens
(Optional) Add a CI workflow that runs a “hello world” compile+deploy test for each combo
Questions for the community:
Which tools are must-haves for your workflow?
Would you prefer YAML/JSON vs. Markdown?
Any ideas for automation (CI, GitHub Actions)?
Excited to hear your thoughts and get this rolling!
Interesting to hear the inputs from the community here.
There are several developments on this front that we can already share.
First, a compatibility matrix of Starknet versions and tools exists in the docs, and it would be great to have more community involvement in sharing and updating it (just open a PR to the docs )
On the Cairo side, a new tool for checking what breaks when a new Cairo versions is released is in development, called Maat.
The purpose of Maat is to:
Check important repositories for successful compilation and test execution when a new version is released
If a breaking change is introduced, understand its effect and make sure it is documented and communicated during the release of the new version
Maat produces a report for new releases and how they affect a wide list of Cairo projects. This gives much more visibility into breaking changes than a simple “hello world”, and covers a wide range of projects, with varying sizes, dependencies etc. The release of Cairo 2.12 is already being checked with this tool.
Currently, Maat is aimed at the new Cairo releases, but will be expanded to new Starknet Foundry releases and Language Server.
For other tools, CLIs and SDKs, we are considering having a more manual, but machine-readable compatibility table. This will serve the purpose of at least answering the question of “what doesn’t work” more easily, within the tools themselves. This has not been officially started yet, and is still in design. If this is something that emerges from the community, it would be great to integrate it
Thanks a lot for the detailed response — this is incredibly helpful and exciting to hear!
The existence of a compatibility matrix in the docs is a great starting point. I’ll definitely take a look and see how we can better support its maintenance and visibility. Making it more community-driven through PRs is a smart move — I’ll encourage others to contribute as well.
Great idea—this would massively improve dev experience and prevent endless version confusion. Markdown is a solid start for accessibility, though YAML could help with automation later. Must-haves: Scarb, starknet-cli, and Voyager. CI with GitHub Actions running basic tests per combo sounds perfect.
)