Hi! Yes, this was my plan once the tests are in and there is confidence in structural changes like this. It is actually a recommended way to handle Gemfiles, as it improves reproducibility of the builds:
https://bundler.io/man/bundle-install.1.html#THE-GEMFILE-LOCK As a result, you SHOULD check your Gemfile.lock into version control, in both applications and gems. If you do not, every machine that checks out your repository (including your production server) will resolve all dependencies again, which will result in different versions of third-party code being used if any of the gems in the Gemfile(5) or any of their dependencies have been updated. Will prepare a pull request -- Dmytro Shteflyuk On December 1, 2025 at 5:03:46 PM, Jens Geyer ([email protected]) wrote: Hi, welcome, and thanks for the PRs already submitted! May I ask something? Could we add what dependabot calls a "supported lockfile" i.e. Gemfile.lock or gems.locked to the repo? That would help a great deal with these (and potentially more): - https://github.com/apache/thrift/security/dependabot/143 - https://github.com/apache/thrift/security/dependabot/142 Have fun, JensG Am 30.11.2025 um 19:24 schrieb Dmytro Shteflyuk: > Hi everyone, > > My name is Dmytro Shteflyuk (aka *kpumuk*). You may have noticed a series > of pull requests from me on GitHub over the last couple of weeks. I’d like > to introduce myself and offer help with modernizing and stabilizing the > Ruby library. After reviewing the codebase, CI setup, and recent > contributions, I wanted to summarize what I’ve observed so far and propose > a possible direction. > Current issues and gaps > > - Several tests are currently failing, including some around > serialization edge cases and platform-specific behavior. > - Supported Ruby versions appear outdated. LANGUAGES.md lists Ruby > 2.3.1p112 to 2.5.1p57 as tested, with the latter reaching end of life in > 2021. The current Ruby release series is 3.3/3.4, with 4.0 planned for > December. Ruby variants like JRuby and TruffleRuby do not appear to have > ever been covered by CI. > - Tests are not running on CI since the Travis CI decommissioning. This > includes cross-library compatibility tests. > - Some protocol features lag behind other language implementations > (e.g., missing UUID support). > - Missing SO_LINGER configuration on sockets, leading to ephemeral port > exhaustion on high troughput deployments > - Recent work on fuzzers does not include Ruby. > - The Ruby gem release process is not automated or secured. > Strengthening supply-chain security using MFA-protected RubyGems.org > accounts and Trusted Publishing would be a good direction ( > https://guides.rubygems.org/trusted-publishing/). > - Code quality is suggested but not enforced — for example, no linters, > and simple issues like trailing whitespace are present throughout the > codebase. > > Recent activity / in-progress work > > I’ve started addressing some of these issues through recent pull requests. > Some are small (e.g., fixing test failures), while others are larger, such > as adding UUID support to the Ruby library and bringing TLS support to the > benchmark script. I also have several more changes in progress to modernize > the codebase and tackle basic maintenance tasks. TCP_NODELAY patch in > accepted sockets was merged, and addresses a significant performance issue > with SSL sockets. > > In parallel, I’ve tried to address several broader issues that affect Ruby > indirectly: > > - Windows build failures on mingw in AppVeyor > - Compiler inconsistencies for UUID constants > - Java cross-library TLS tests > > These were done mainly to unblock Ruby work and to help stabilize CI and > cross-language compatibility. > Next steps > > Before sending a large number of additional patches, I would appreciate > feedback on a few points: > > - Is there interest in improving the Ruby library? Is there a roadmap or > direction I should align with? > - Are there specific issues or areas where help would be most valuable? > - What should be the minimum supported Ruby version? Should we align > with official Ruby end-of-life policy (https://endoflife.date/ruby)? > > I’m happy to start wherever the community believes the priorities are > highest. I look forward to collaborating with everyone. > > – > Dmytro Shteflyuk >
