Redmine

+1

• Ruby 2.1 and earlier should no longer be used. ( https://www.ruby-lang.org/en/news/2017/04/01/support-of-ruby-2-1-has-ended/ )
• Supporting ancient versions of Ruby is big burden for plugin developers.

Hi, this will block my upgrade to 3.4.0 in my Ubuntu 14.04 LTS and OpenSuSE 42.2# and probably other distros.

Shouldn't this be put in 4.0.0 like #23630 and #19755 ?
Given some more time to users to plan system upgrades ?

I agree, dropping support for Ruby versions should probably be done in a major version instead.

That said, dropping Ruby 1.9.3 support is probably a good idea in the short-to-middle term since it is seriously old and not supported by the Ruby language team for quite some time. For other versions, I'd be actually more careful.

• Ubuntu 14.04 LTS defaults to Ruby 1.9.3, but also ships with Ruby 2.0. Ubuntu 16.04 LTS ships with Ruby 2.3 by default.
• Debian stable (Jessie) currently ships with Ruby 2.1. The next stable (which is just around the corner) will ship with Ruby 2.3
• RHEL/CentOS 7 ships with Ruby 2.0 currently, RHEL/CentOS 6 still ships Ruby 1.8.7.
• OpenSuSE 42 ships with Ruby 2.1

Given this landscape, in order to provide the broadest possible support for existing users, I'd propose to only drop Ruby 1.9.3 support in the short term (if at all, see below). I understand that is is desirable to also drop at least Ruby 2.0 but this would seriously inconvenience many people who have to use older Ruby versions from their upstream vendors. Thus, I'd propose to only follow this approach now if the gain of not supporting older Ruby 2.x versions is actually significant.

In general, I think that the removal of supported Ruby versions should be done in a major version bump only. With the release of Redmine 4, I'd be quite happy if only Ruby >= 2.2 would be supported. Given that Rails 5 requires Ruby >= 2.2.2 anyway, this is probably a given requirement. Until then, I'd propose we still support the existing Ruby versions in all existing and future 3.x-stable branches.

We can unpin test_after_commit gem 0.4 if Ruby 1.9.3 support is dropped (#25794, r16582).

https://github.com/sparklemotion/nokogiri/pull/1640#issuecomment-301805320

The 1.6.8.x release isn't supported anymore, and we're encouraging teams to upgrade to get security patches.

As a concrete motion from my side:

• I think it's a god idea to require at least Ruby 2.2.2 (or whatever Rails depends on at this time) from Redmine 4 on.
• Removing support for 1.9.3 could be sensible in Redmine 3.4 if that aligns with the the way Redmine want's to support Rubies in general. Ruby 1.9.3 is not maintained by the upstream Ruby for quite some time now and no halfway modern OS ships with Ruby 1.9.3 anymore.
• I don't think it is a good idea to remove support for Ruby 2.0 in Redmine 3.4 as this would alienate many RHEL / CentOS users. I would be fine with showing a deprecation warning in Redmine 3.4 for anything <= Ruby 2.1 though. Redmine should still work as far as possible even on Ruby 2.0.

In general, I think it is worth it to define how Redmine plans to handle support to external dependencies like Ruby, Rails or nokogiri (e.g. with #26183) in general. If there is a commitment from the Redmine project to ensure that all dependencies are ensured to be secure, the Redmine project probably has to follow the support cycles of these dependencies too. That would mean to regularly issue patch releases with updated dependencies and to either EOL Redmine versions depending on not supported dependencies or provide monkey patches for them. This issue of how we define our policy was also discussed in https://github.com/rails/rails/pull/27814.

Policy wise, I think this would significantly increase the burden on the project for too little gain. I think we could follow our current best-effort way to provide updates while still striving to be as compatible as possible to a wide version range of external dependencies. As for Ruby compatibility, Redmine has historically attempted to follow the requirements of its respective Rails version. This has allowed Redmine to be used on a wide array of configurations and systems.

Even more so: at Planio we often notice that many Redmine installation are not (or only very seldom) updated. Making it harder to update Redmine by introducing stricter environment dependencies (like a Ruby version) could likely result on even poorer update rates which effectively has a negative effect on overall security (Yes, this is a hard problem!)

Still, it is probably a good idea to nudge users in the direction of a preferred Ruby version and updated dependencies if possible. That way, people with specific requirements can still use other versions but the general population is still nudged into the sweet spot. Hard dependency updates of the environment should however be limited to major version updates if at all possible. This also helps packagers who maintain e.g. the redmine package in Debian (and by extension Ubuntu).

+1 for Holger Just.

Go MAEDA wrote:

+1 for Holger Just.

I agree.

Debian 8, CentOS 6 and Ubuntu 14.04 have Ruby 1.9.3 installed by default (although ruby 2.* is also available from the repos). These operating systems are installed on a lot of servers. Switching to ruby2 as default is not always possible there.

Vasili Korol wrote:

Debian 8, CentOS 6 and Ubuntu 14.04 have Ruby 1.9.3 installed by default (although ruby 2.* is also available from the repos). These operating systems are installed on a lot of servers. Switching to ruby2 as default is not always possible there.

• Debian 8 (Jessie) uses Ruby 2,1 by default, Debian Stretch (just released) uses 2.3. Only Debian 7 (Wheezy aka. oldoldstable) used Ruby 1.9.3
• While Ubuntu 14.04 (Trusty) installs Ruby 1.9.3 by default, you can install ruby2.0 alongside with it.
• I personally don't care about CentOS/RHEL 6 anymore. It was released 6 years ago and about everything on there is heavily outdated. CentOS 7 is available since three years.

By continuing to support such extremely old (and mostly unmaintained) software, we would enter a world of pain and would continuously force us to not use any of new features available in later versions and work with older (often also unsupported) versions of gems. If users want to continue using outdated base systems, they can always install a custom Ruby with RVM, ruby-install or rbenv/ruby-build when upgrading Redmine.

Again, support for external dependencies (most importantly Ruby, but also other gems) is always a tradeoff between the required effort for the maintenance and compatibility with existing systems. Redmine currently supports a lot of even very old systems which is increasingly becoming painful. Cutting support for the most outdated systems first in a controlled manner helps (in lieu of saying: is required) for the Redmine project to be able to continuously maintain and modernize its codebase. Cutting support for old dependencies with newer releases is a standard practice followed by about any software package.