feat: Add Ruby 3.2 to the test matrix #896
Conversation
|
I think dropping <3.0 makes sense, and is in line with the policy stated in the README
By the same logic we could drop 3.0 as of the end of the month, but assuming it's not blocking anything else, you could keep it an extra year until April 2025. I think 3.1 should be added to keep in line with the policy and possibly also 3.3? |
|
Is there any reason you want to reduce the number of tmux versions? Is backwards compatibility blocking anything? |
|
The introduction of Ruby > 3.0 causes rubocop to fail. I've attempted upgrading; it's quite a big task. I think we have to get to v0.61.0 to get this fix.
We're currently testing against 3.1, 3.1a, 3.1b, and 3.1c; tmux appears to follow semver conventions, where there are expected to be no breaking changes between 3.1 and 3.1c. I don't really feel that strongly about reducing the tmux versions list if there's a good reason to test against each version like this. |
|
Nice. Are you running into any blockers when upgrading rubocop? |
Like I said, I don't really see a point in dropping any of the versions even if they don't do anything. At worst it's just a bit of wasted compute on the microsoft servers. |
|
Rubocop adds cops as it upgrades, and we have some failing new cops. One way to upgrade is to rely on It also seems like upgrades between major versions of rubocop (i.e. 0.x -> 1.x -> 2.x) have more than just new cops. Many cops are renamed, split, or merged into other cops. I'll open a PR at some point when I get it to a good state, but no promises on timeline. 😄 |
|
Ok. Let me know if you need help on anything. |
|
I've rebased this PR on top of #905 to demonstrate rubocop works with all existing supported versions of ruby in addition to 3.1 and 3.2. |
Signed-off-by: Andrew Kofink <ajkofink@gmail.com>
Signed-off-by: Andrew Kofink <ajkofink@gmail.com>
Signed-off-by: Andrew Kofink <ajkofink@gmail.com>
Signed-off-by: Andrew Kofink <ajkofink@gmail.com>
|
Closing this in favor of #907 |
This PR is mostly to demonstrate the issue solved by #889
For further discussion
It's sort of unclear which versions of Ruby we want to test against at the moment. Based on the ruby maintenance schedule, Ruby < 3.0 was end of life as of 2023-03-31.
I'm open to the idea of cleaning up the test matrix and removing Ruby 2 support for tmuxinator.
Ruby 3.0 is also going end of life quite soon, 2024-03-31. How long should we continue testing with it after EOL?
Should we also maybe test against Ruby 3.1?
We're also testing against literally all versions of tmux since 1.5.
Would it make sense to at least collapse
3.1[,a,b,c]to just3.1c?Happy to report an issue for this discussion about which versions we want to support and test against.