Deprecation of Ruby 2.5

Ohai,

with Foreman 3.4 dropping Debian 10 support (see Deprecation plans for Foreman on EL7, Debian 10 and Ubuntu 18.04), we’ll end up with all supported platforms running with Ruby 2.7.

Therefor I’d like to also deprecate Ruby 2.5 support in Foreman altogether, and remove it in 3.4.

This would mean less time spent in CI (at least as long we don’t add Ruby 3.0 in the future), and fewer obscure Ruby bugs (like https://bugs.ruby-lang.org/issues/14373).

The only downside that I could see is that this would mean we’d need to bump the “start” version of our upgrade tests. They currently start at Foreman 1.21 with Ruby 2.5, but I am not sure that version supports 2.7 too. Foreman 2.5 certainly does, as that’s the version we switched to 2.7 by default on EL7 and introduced Ubuntu 20.04 Focal.

I have opened a PR against the 3.3 release notes to express this:

6 Likes

I was looking at turning the Foreman PR jobs into Jenkins pipelines when I remembered this thread and went back to read it as I want to convert only what is necessary. That got me to the question of: what does the test_develop_pr_upgrade job actually do and does it still provide value enough to convert it?

The text comment in the job says:

“# The idea is to test that older DB migrations don’t break when models are changed.”

I got to wondering if this is really a problem anymore and if this job would truly catch all instances of this compared to our actual upgrade pipelines. I am not aware of any other code base running such a test on PRs.

The goal of the upgrade job is to test the DB data migrations. The problem with this job is that it actually has very little data (just what db:seed creates) so it has limited coverage.

In the past we’ve bumped the lower version bound we upgrade from, but another solution may be to have some stored database dumps with non-trivial data and migrate those. That would be more likely to show issues.

The proposal around the job is to:

  • Drop the current incarnation of the job instead of trying to re-write it
  • Work on getting a database dump we can use for testing and run this style test with a database dump