Closed CHTJonas closed 5 years ago
Thanks!
@toland @CHTJonas Sorry I am late with this, but once we do this we effectively drop support for older Rubies since we won't know they are going to break. We haven't dropped support for those Rubies officially, and when they have been removed from Travis if we introduce a regression with compilation or syntax that no longer works on the older versions we are going to be letting our users down.
Not saying we should revert this but maybe we should do this in a more considerate way.
Totally hear what you're saying @julik. I'd say maybe add 2.0 thru 2.2 to 'allowed failures' but maybe leave 1.9 out fully. I think we can be forgiven for thinking that there isn't anyone still using a Ruby version which ended support in 2014 and security maintenance in 2015 but that just my two cents. I'm happy for the old version to be added back to the Travis build.
Maybe we should branch off a version with 1.9.3 support and continue 0.x there, and set master off to a trajectory towards 1.0? We can then also ditch a number of archaic things such as GVL treatment, introduce keyword arguments and so forth. @toland if you are OK with this I will prep a branch for 0.x support and do the README alterations?
@julik Sorry, I was traveling for a conference last week and more distracted than normal.
I love the idea of creating a branch for the older versions of Ruby/Patron and getting a 1.0 release out on modern Rubies.
if you are OK with this I will prep a branch for 0.x support and do the README alterations?
Go for it.
Hi! 👋
This PR configures Travis to run the test suite against all currently supported versions of Ruby, plus head. It also includes the build status at the top of the README for those in a hurry.
See: https://en.wikipedia.org/wiki/Ruby_(programming_language)#Table_of_versions