-
Notifications
You must be signed in to change notification settings - Fork 55
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
Compatibility matrix strategy #313
base: main
Are you sure you want to change the base?
Conversation
Example on how one can maintain a compatibility matrix
ofc we can rename the |
erlang: | ||
- otp: "17" | ||
rebar3: "3.10.0" | ||
os: ubuntu-18.04 |
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.
ubuntu-18.04 is no longer available.
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.
ok, I'll remove OTP17-20 from Readme.
rebar3: "3.22.1" | ||
os: ubuntu-latest | ||
steps: | ||
- uses: actions/checkout@v2 |
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.
- uses: actions/checkout@v2 | |
- uses: actions/checkout@v4 |
Description
Example on how one can maintain a compatibility matrix.
Note I've not tested keeping the os-version in the strategy itself, but according to the github documentation it works for the runs-on argument as well.
I'm currently running otp-rebar pinning for another project for OTP22-OTP27 versions below.
And I ran a similar thing (though not with erlef/setup-beam) previously for the same project for OTP17-21.
I'll add the os-version to my project for testing, but I wanted early feedback on your thoughts.