Support only Ruby 3.1 onwards

[trichoplax]

Currently we test Ruby 2.7 and Ruby 3.1. Ruby 3.1 will reach end of life on 2025-03-31, and Ruby 2.7 has already passed end of life.

This pull request stops testing Ruby 2.7 and starts testing Ruby 3.2. The intention is that we will continue to test the oldest minor version that is still supported (has not reached end of life) plus the minor version after that, so that the tests ensure we are always ready to stop using a version when it reaches end of life.

For example, on 2025-04-01 when Ruby 3.1 is no longer supported, we can switch from testing 3.1 and 3.2 to testing 3.2 and 3.3.

[Oaphi]

TODO list:

• update documentation to mention that we switched to 3.1 / 3.2 (or, better yet, add badges);
• update Docker configuration to use Ruby 3.2;

[trichoplax]

• update documentation to mention that we switched to 3.1 / 3.2 (or, better yet, add badges);

Would the badges be 2 test outcome badges, one for 3.1 and one for 3.2?

• update Docker configuration to use Ruby 3.2;

One possibility I was imagining was keeping this at 3.1 until a second pull request is merged on 2025-04-01 to change the testing to 3.2 and 3.3, and change the Docker config to use 3.2. Alternatively we could change the Docker config to use 3.2 in this pull request, and change it to use 3.3 on 2025-04-01.

I don't know whether any instances are using Docker in production, and whether that would affect this decision.

[Oaphi]

Would the badges be 2 test outcome badges, one for 3.1 and one for 3.2?

Don't have a strong opinion on that, but 2 badges, one for each target, sounds reasonable to me

One possibility I was imagining was keeping this at 3.1 until a second pull request is merged on 2025-04-01

d'oh, I haven't paid attention to the PR's description... Well, this item is mostly to ensure I don't forget to do so as promised, we can merge without it if I end up not being available to make good on that promise in a timely fashion.

[trichoplax]

Would the badges be 2 test outcome badges, one for 3.1 and one for 3.2?

Don't have a strong opinion on that, but 2 badges, one for each target, sounds reasonable to me

I had a look at the instructions for making a CircleCI badge.

The current badge (at the top of the readme) appears to be a build status badge. I tried the URL structure for a workflow badge, using workflow test_lint but I couldn't get it to work. I don't have access to generate a badge through the web interface but it seems like that should only be necessary for a private repo where a token is required.

I can't see where I'm going wrong, but if someone knows how to get a workflow badge working I'm guessing we could split test_lint into 2 separate workflows in order to give a badge per minor version of Ruby?

The following works for a build status badge:

<a href="https://circleci.com/gh/codidact/qpixel"><img src="https://circleci.com/gh/codidact/qpixel.svg?style=svg" alt="CircleCI Build Status"></a>

giving

However, the following doesn't seem to work for a workflow status badge:

<a href="https://circleci.com/gh/codidact/qpixel"><img src="https://circleci.com/gh/codidact/qpixel/test_lint?style=svg" alt="CircleCI Build Status"></a>

giving (just the alt text rather than an SVG badge).

That was omitting the .svg that a build status badge URL has, following the instructions for a workflow badge, but including the .svg also doesn't seem to work:

<a href="https://circleci.com/gh/codidact/qpixel"><img src="https://circleci.com/gh/codidact/qpixel/test_lint.svg?style=svg" alt="CircleCI Build Status"></a>

again giving just the alt text:

[trichoplax]

Having separate badges for results of testing Ruby 3.1 and 3.2 seems impossible with CircleCI without ongoing manual workarounds with separate branches, so I've left just the single badge for now. Splitting into 2 might be worth considering once we move away from CircleCI.

Previously the Ruby versions supported were mentioned only in INSTALLATION.md, and not below the badge in README.md. Unless anyone needs them to also be mentioned below the badge, I'll leave it this way to reduce the number of places that need updating each year when we move to the next minimum supported version.

If you're happy to leave the Docker configuration using 3.1 until we update the minimum supported version to 3.2 on 2025-04-01, is this pull request ready to merge now?