Breaking change with 3.3.0

[cyberious]

Going from zero ruby requirements to requiring 2.5.0 is a breaking change. We now have a bunch of things breaking due to this latest requirement to ruby >= 2.5.0.

Is there a reason to not just create this as 4.0 and force that requirement on the next major version instead? Is this a actual requirement due to library usage, is 2.4.x not compatible.

[cyberious]

If I am not mistaken the reasoning for this has to do with Ripper::Filter and adding the ability of state for the extractor, love the addition but... https://ruby-doc.org/stdlib-2.4.9/libdoc/ripper/rdoc/Ripper/Filter.html

[cdenneen]

Had to force version to < 3.3.0 to fix this but would appreciate this to be corrected upstream. 3.3.0 pulled possibly.

[kou]

What is solved by using 4.0.0 instead of 3.3.0?

[kou]

If I am not mistaken the reasoning for this has to do with Ripper::Filter and adding the ability of state for the extractor, love the addition but... https://ruby-doc.org/stdlib-2.4.9/libdoc/ripper/rdoc/Ripper/Filter.html

Right.

[kou]

would appreciate this to be corrected upstream.

Does it mean that gettext should support Ruby 2.4 again?

Ruby 2.4 will reach EOL at 2020-03.

https://www.ruby-lang.org/en/news/2019/10/02/ruby-2-4-9-released/

Ruby 2.4 is now under the state of the security maintenance phase, until the end of March of 2020. After that date, maintenance of Ruby 2.4 will be ended. We recommend you start planning the migration to newer versions of Ruby, such as 2.6 or 2.5.

If gettext supports Ruby 2.4 again, gettext will drop support for Ruby 2.4 at 2020-04.

[joshcooper]

What is solved by using 4.0.0 instead of 3.3.0?

It's common for a project to express a pessimistic constraint on a dependency like gettext as '~> 3.0'. That way a project will accept all versions of gettext between >= 3.0 and < 4 with the understanding that backwards incompatible changes won't be made in a 3.x release. However, dropping ruby < 2.5 support in 3.x is a breaking change for any project that still supports older ruby versions.

It would be great if you could revert the minimum ruby version in gettext 3.3.1, and release a 4.0 version that requires ruby 2.5 or greater.

[kou]

How many projects that use ~> 3.0?

If a project uses Bundler, Bundler chooses gettext 3.2.9 for Ruby 2.4:

$ cat Gemfile
source "https://rubygems.org/"
gem "gettext"
$ bundle install
Don't run Bundler as root. Bundler can ask for sudo if it is needed, and
installing your bundle as root will break this application for all non-root
users on this machine.
Fetching gem metadata from https://rubygems.org/..
Resolving dependencies...
Using bundler 2.1.4
Fetching locale 2.1.2
Installing locale 2.1.2
Fetching text 1.3.1
Installing text 1.3.1
Fetching gettext 3.2.9
Installing gettext 3.2.9
Bundle complete! 1 Gemfile dependency, 4 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.

What use case do you assume?

[joshcooper]

How many projects that use ~> 3.0?

That's fairly common for gems that follow semver, where breaking changes are only supposed to happen on a major version boundary.

If a project uses Bundler, Bundler chooses gettext 3.2.9 for Ruby 2.4:

It will work for a trivial Gemfile like you have above. But there's no guarantee bundler will take into account the minimum required ruby version for all of its dependencies, especially as the number of dependencies increases. For example, https://github.com/bundler/bundler/issues/5425 is supposed to be fixed, but isn't entirely.

[kou]

How many projects that use ~> 3.0?

That's fairly common for gems that follow semver, where breaking changes are only supposed to happen on a major version boundary.

Then how many gems follow semver?

I want to discuss with real data instead of your feeling. For example, gettext-setup-gems didn't assume semver: https://github.com/puppetlabs/gettext-setup-gem/pull/75

If a project uses Bundler, Bundler chooses gettext 3.2.9 for Ruby 2.4:

It will work for a trivial Gemfile like you have above. But there's no guarantee bundler will take into account the minimum required ruby version for all of its dependencies, especially as the number of dependencies increases. For example, rubygems/bundler#5425 is supposed to be fixed, but isn't entirely.

Could you show a real failure case instead of "it may fail".

Anyway, we should fix Bundler instead of spreading a workaround if Bundler has a problem.

[Nikerabbit]

Could you show a real failure case instead of "it may fail".

https://integration.wikimedia.org/ci/job/translatewiki-rake-docker/302/console, worked around with https://gerrit.wikimedia.org/r/c/translatewiki/+/563173

[kou]

Your Bundler is old:

13:08:00 Using bundler 1.13.6

The latest Bundler (2.1.4) doesn't have the problem.