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

CI run with minimum versions of dependencies #15136

Open
cameel opened this issue May 23, 2024 · 3 comments
Open

CI run with minimum versions of dependencies #15136

cameel opened this issue May 23, 2024 · 3 comments
Labels
low effort There is not much implementation work to be done. The task is very easy or tiny. low impact Changes are not very noticeable or potential benefits are limited. should have We like the idea but it’s not important enough to be a part of the roadmap. testing 🔨

Comments

@cameel
Copy link
Member

cameel commented May 23, 2024

Currently we only consistently test the code with one set of dependency versions on each platform. It's usually either the latest one of the one installed by default. If we use anything else, it's coincidental - when a different version happens to come with some non-standard CI image.

As pointed out in #15117 (comment), we should really have a CI run with the minimum supported versions to detect breakage. In most cases this breakage is harmless, because it only results in a failure to build, but there have been cases of semantic changes in Boost that resulted in the compiler producing different output (e.g. boostorg/multiprecision#129 or all the various changes to boost::filesystem that affect import processing). Nowadays these will often be caught by tests, but to catch them, have to run them in the first place.

I think it would be enough to have such a run on Linux, as we support the widest range of versions, so it should catch vast majority of problems of this kind.

@cameel cameel added testing 🔨 low effort There is not much implementation work to be done. The task is very easy or tiny. low impact Changes are not very noticeable or potential benefits are limited. should have We like the idea but it’s not important enough to be a part of the roadmap. labels May 23, 2024
@zerosnacks
Copy link

zerosnacks commented Jul 11, 2024

Hi @cameel,

Is there a table or resource I can reference for what the minimal required OS version is to run solc on each platform?

This would be useful for Foundry so we can keep our minimal build targets in sync.

Related: foundry-rs/foundry#7253

Edit: I did find https://docs.soliditylang.org/en/v0.8.24/installing-solidity.html#prerequisites-all-operating-systems but it does not list the minimal OS version

@cameel
Copy link
Member Author

cameel commented Jul 13, 2024

@zerosnacks Not really, we don't target specific OS versions, it's implicit in whether they provide the necessary dependencies. And even then it's mostly about building the compiler. At runtime the static binaries should work pretty much anywhere. Well, the ones we build ourselves and distribute are not always completely static (e.g. Linux ones dynamically link to Z3, which will not work with a very old glibc), then emscripten build is the fallback.

Copy link

This issue has been marked as stale due to inactivity for the last 90 days.
It will be automatically closed in 7 days.

@github-actions github-actions bot added the stale The issue/PR was marked as stale because it has been open for too long. label Oct 11, 2024
@cameel cameel removed the stale The issue/PR was marked as stale because it has been open for too long. label Oct 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
low effort There is not much implementation work to be done. The task is very easy or tiny. low impact Changes are not very noticeable or potential benefits are limited. should have We like the idea but it’s not important enough to be a part of the roadmap. testing 🔨
Projects
None yet
Development

No branches or pull requests

2 participants