Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Supported Ruby versions? #7

Open
jgarber623 opened this issue Jun 3, 2024 · 4 comments
Open

Supported Ruby versions? #7

jgarber623 opened this issue Jun 3, 2024 · 4 comments

Comments

@jgarber623
Copy link
Contributor

jgarber623 commented Jun 3, 2024

Hello!

First off, thanks for keeping this gem going for 15+ years. Also, I acknowledge the note in the README regarding the project's current status. So, if you don't feel like addressing the following, I completely understand.


This gem incidentally supports any Ruby version since it doesn't specify a required_ruby_version in its gemspec. I'd be interested in knowing more about that choice and whether or not you'd be open to implementing a minimum required Ruby version of some kind.

Given the popular libraries that depend on this gem, a choice of a minimum supported Ruby version should be carefully considered.

Most notably, pdf-reader (65 million downloads) specifies ruby >= 2.0. pdf-reader is a development dependency of prawn (60 million downloads) which itself specifies ruby >= 2.7.

Additionally, implementing a minimum supported Ruby version would:

  • streamline CI and resolve the current Ruby 2.2 failures
  • obviate (I think) the need for # -*- encoding: utf-8 -*- magic comments

While it's been EOL'ed since March 2023, Ruby 2.7 as a minimum would be my choice (to the degree that I have a vote!).

Thanks for considering! I'd be happy to PR a change if any of the above is reasonable.

@DataWraith
Copy link
Owner

Hello,

thank you for your interest, and sorry for the late reply -- my last two weeks have been very, very busy.

My policy so far has been to try to support all Ruby versions going back to 1.8, when I originally wrote the gem, because you can never really be sure if there is not someone still depending on it. The project is feature-complete, so my main task is to keep it working for everyone who depends on it.

At this point, you're right that approximately no-one is still on 1.8, and in fact, it is very difficult to even install Ruby 1.8 on a modern operating system. I failed to do that a few weeks back when I made the last point release, so I definitively should raise the minimum Ruby version.

However, the code is pretty old, and I made a few mistakes that should really be dealt with by a complete rewrite and a 2.0.0 release. There's the boneheaded decision of requiring strings to be wrapped in <~ and ~> before decoding, and the ascii85 executable also isn't all that useful.

Long story short: The gem is due for a complete re-write, but I'm not sure when or even if I will find the motivation and time to do that. I probably won't mess with the minimum supported version until that rewrite happens, at which point I will release a new major version with a Ruby 2.7 or 3.0 constraint.

@DataWraith
Copy link
Owner

I have decided to raise the minimum supported Ruby version to 2.7 with the upcoming 2.0.0 release.

I had some spare time to refactor and improve the code; the gem now allows streaming encoding/decoding from/to files or other IO-like objects. It's also about 33% faster as a result of the changes (though an actual benchmarking harness is still TBD).

I hope to be able to publish the new version within two weeks, after some more testing and fixing.

@jgarber623
Copy link
Contributor Author

@DataWraith Thank you for the thoughtful replies! I appreciate it and hopefully this week is less busy than the previous weeks.

That's great news about the upcoming v2.0.0. Are you looking for any help getting that across the finish line, reviewed, tested, or anything similar?

@DataWraith
Copy link
Owner

Thank you for your offer! If you can spare the time, it would be great to get feedback on the code itself: is anything unclear? Unidiomatic? Could something be done more efficiently? Did I miss some obvious edge-case?

I'm done with all changes I had planned for v2 now, and while I'm fairly confident that everything is working now that CI is green, a second pair of eyes to look at the code would be very welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants