Remove {1.8.7,ree} support

[tamird]

Not sure if you're prepared to do this, but thought I'd put it out there.

[sodabrew]

I'm comfortable carrying 1.8.7 for the rest of 2015. The cost of #ifdef Encoding macros is annoying but not onerous.

[tamird]

Alrighty. I'll just leave this here, since it documents some unfortunate rubinius-related discoveries.

[sodabrew]

No kidding, though. I'm surprised that Rubinius is missing those. I wonder if rb_wait_for_single_fd will be easy or difficult to implement upstream in their IO architecture.

[tamird]

Rebased.

rb_hash_dup was added to RBX in rubinius/rubinius#3432, but rb_wait_for_single_fd is still missing (tracked in rubinius/rubinius#3073).

[nurse]

Now year 2016, Ruby 1.8.7 is still required?
Current CI status for Ruby 1.8.7 is badly broken.

[jeremy]

Dropping support for old EOL Ruby is sensible (and popular).

However, it's worth noting that mysql2 is often an critical "bridge" library that helps older 1.8.x software gracefully upgrade to 2.x.

When that bridge goes away, more software is stranded on 1.8. It may be worth a little extra effort to maintain 1.8 support for our users who are working to upgrade. We're the ones who can offer them a helping hand.

That said, another route is to freeze a 1.8-compatible stable branch that we also guarantee works with latest Ruby 2.x. Then old software can gracefully upgrade Ruby on the old mysql2 (which works on EOL and current Ruby), then upgrade to current mysql2 separately.

[tamird]

Rebased this; mariadb 10.0 and 10.1 failed during extconf:

$ bundle exec rake
mkdir -p tmp/x86_64-linux/mysql2/2.4.1
cd tmp/x86_64-linux/mysql2/2.4.1
/home/travis/.rvm/rubies/ruby-2.4.1/bin/ruby -I. ../../../../ext/mysql2/extconf.rb
checking for rb_absint_size()... yes
checking for rb_absint_singlebit_p()... yes
checking for ruby/thread.h... yes
checking for rb_thread_call_without_gvl() in ruby/thread.h... yes
checking for rb_wait_for_single_fd()... yes
checking for mysql_query() in -lmysqlclient... no
-----
mysql client is missing. You may need to 'apt-get install libmysqlclient-dev' or 'yum install mysql-devel', and try again.
-----
*** ../../../../ext/mysql2/extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.
Provided configuration options:
	--with-opt-dir
	--without-opt-dir
	--with-opt-include
	--without-opt-include=${opt-dir}/include
	--with-opt-lib
	--without-opt-lib=${opt-dir}/lib
	--with-make-prog
	--without-make-prog
	--srcdir=../../../../ext/mysql2
	--curdir
	--ruby=/home/travis/.rvm/rubies/ruby-2.4.1/bin/$(RUBY_BASE_NAME)
	--with-mysql-dir
	--without-mysql-dir
	--with-mysql-include
	--without-mysql-include=${mysql-dir}/include
	--with-mysql-lib
	--without-mysql-lib=${mysql-dir}/lib
	--with-mysql-config
	--without-mysql-config
	--with-mysql-dir
	--without-mysql-dir
	--with-mysql-include
	--without-mysql-include=${mysql-dir}/include
	--with-mysql-lib
	--without-mysql-lib=${mysql-dir}/lib
	--with-mysqlclientlib
	--without-mysqlclientlib

Any idea what might've caused that?

[jaredbeck]

As we approach 2018, with important libraries like rails dropping support for ruby < 2.2, and in fact the EoL of 2.2 only five months away, it's surprising to see a library still support 1.8.7!

I wish we had better data on this, but the only survey I'm aware of is the Rails Hosting Survey 2016:

This survey is nearly two years out of date, and shows ~7% of apps running ruby < 1.9.3. I hope they run the survey again in 2018.

My vote would be to drop support if it would help in any way with maintenance or performance.

[sodabrew]

Performance is not impacted at all. Maintenance burden is light. That said, 2018 is time to call it.

[sodabrew]

Thanks for rebasing again after all this time! Since the rb_wait_for_single_fd file ends up unchanged, would you squash that commit into the previous one with the effect of not affecting the file history in the PR?

[tamird]

No problem! Done.

…

On Sat, Nov 25, 2017 at 2:12 AM, Aaron Stone ***@***.***> wrote: Thanks for rebasing again after all this time! Since the rb_wait_for_single_fd file ends up unchanged, would you squash that commit into the previous one with the effect of not affecting the file history in the PR? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#632 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABdsPGuOAPwUphhqm6rWexaZXmr25tpRks5s573ogaJpZM4E-S8u> .

[sodabrew]

BOOM!