Closed deivid-rodriguez closed 7 years ago
It was supporting Rails 2.3 and Ruby 1.9.3 because the only project I used this gem for many years was a legacy Rails 2.3 app. 😆 Like the actual Rails 2.3 LTS version: https://github.com/makandra/rails
It is my sense that this gem, being 10 years old, has a large base of legacy users, but I haven't really gathered any data on that topic.
The only reason the build began failing for Ruby 1.9.3 was some gems that weren't locked began requiring Ruby >= 2.0 (like tins
). I'll see if I can easily fix that.
I can't drop support for a Ruby without bumping a major version, so it would mean a 1.0 release (finally!) which I am hoping to get to, but I wanted to do a rewrite of the internals before then.
You not only need Rails 2.3 users for a reason to keep support. You need Rails 2.3 users who want to upgrade this gem but stay on Rails 2.3. That's incredibly weird.
Also, you're in version 0.x, you should feel free to do what you want with your version support if it simplifies maintenance. You don't need 1.0.0. If you don't think this gem is ready to call it 1.0.0 without a rewrite, that's very reasonable. But that doesn't mean you can't drop support for anything. My two cents.
I suppose we could do minor releases dropping support. I will consider dropping Rails 2.3 for the 0.4 release.
Ok, I rebased this PR for you in case it's useful for the future!
excellent, thanks. I will merge this once I move master to target the 0.4 release, which should be in the next week or so.
I do still want to do this! I just haven't had much time. I'll reopen when I can get to it.
I was very surprised that this gem supported Rails 2.3. After checking Travis, it seems like it does not, so this is just cleaning up, not actually dropping anything since it's already broken.
You should drop support for EOL'd Rails and Ruby versions though (Rails 3.0, 3.1, 3.2, 4.0, 4.1, MRI 1.9.3, 2.0, 2.1).