Bundler lives in the RubyGems repository, the two share a version number, and the licence is two files the metadata cannot classify

Bundler is in this repository, and the two are versioned as one product

The first thing that surprises people is that Bundler lives here. Bundler is the dependency resolver, and the readme states plainly that it is developed in this repository and ships with Ruby. Its job is to make sure a Ruby application runs the same code on every machine, which it does by managing the gems the application depends on: it downloads and installs those gems plus the gems those gems need, it checks the versions of everything before installing so they are compatible and can all be loaded at once, it can update some or all of them when new versions appear, and it records the exact versions installed so another machine reproduces them. Four commands cover the common path:

bundle init
bundle add rspec
bundle install
bundle exec rspec

Because RubyGems and Bundler share a version number and are released together, a RubyGems upgrade moves Bundler with it.

The release policy is written down and it explains the tag order

Most projects of this age do not publish one, so the policy section is worth reading rather than skipping. The cadence is stated in three tiers, and the first one is unusually concrete: patch releases every two to four weeks, carrying bug fixes, minor enhancements, small features, and even medium-sized features if they are declared experimental for battle testing. Yearly minor releases carry the bigger features and the minor breaking changes, and the scope of those is bounded in the text, affecting only edge cases and a very small set of users. Major releases are occasional and replace the yearly minors. Now look at the tag dates. A 4.1.0 beta shipped on 2026-09-09, then a 4.0.21 patch on 2026-09-16, then a 4.0.22 patch on 2026-09-30. That is the policy in action: the experimental features go out on the next minor first, and the patch line keeps moving underneath.

Manual installation is one script, with a warning against operating system packages

The install section exists for a minority, and it is opinionated about them. RubyGems is already present in any Ruby environment, and the check is a single version query on the gem command. If your Ruby came from an operating system package, the readme says plainly that this is not a recommended way to run Ruby or RubyGems, and points at version managers such as rbenv and chruby instead. The nuance is what to do if you keep the system version anyway: upgrade RubyGems with the same package manager that installed it, and disregard every other installation instruction in the document. Manual installation itself has two routes, downloading an archive and changing into its source directory, or cloning this repository and changing into that, and then running the setup script, whose help output lists the remaining options.

Two gemspecs, two test runners and a hand-maintained file list

The repository publishes more than one gem, and it is worth knowing which is which before you look at the tree. There is a Bundler gemspec and a separate RubyGems update gemspec, so the self-update mechanism ships as its own package. There are also two test directories rather than one: a spec directory for the RSpec suite, with its own configuration file, and a test directory for the older test-unit style with its own configuration alongside. That is unusual for a project this size and it is a maintenance cost you inherit if you contribute. A manifest file at the root lists the files that go into the package, which means adding a file to the gem is a deliberate edit rather than an automatic one. The build itself is driven by a Rakefile, and there are separate bin and exe directories for the two kinds of entry point.

One directory is named after the update procedure, which is not a convention

There is a directory in the root whose name is an instruction rather than a category: it hides the library while the system update runs. That is a name you only understand once you know what the update command does, and it tells you something true about this project. When you upgrade RubyGems, the copy of the library you are currently running has to get out of the way of the copy being installed, and instead of hiding that in a script the repository keeps the mechanism as a directory in the open. Two other directories follow the same habit of naming a process rather than a subject: a hooks directory for local git hooks, and a development container directory. Both mean the workflow around the code is versioned, so a new contributor gets the same setup a maintainer uses instead of a paragraph in a document.

Two licence files sit in the root and the repository metadata claims nothing

The licence situation is odd enough to check rather than assume. There are two licence files at the root: one named for the general terms and one named MIT. And yet the licence field in the repository metadata could not be determined automatically, which is why this article cannot tell you the single licence that covers the code without opening both files. That is not a rhetorical point, it is a practical one for anyone vendoring or re-licensing: the answer is in the files, not in the metadata. Alongside them sit a security policy, a contributing guide, a code of conduct whose scope is spelled out as covering codebases, issue trackers, chat rooms and mailing lists rather than only commits, and a change log configuration file, which suggests release notes are generated from commit data rather than written by hand.

The public gem repository is operated by somebody else

The service and the code have different owners, and the readme is clear about it. RubyGems.org, the public repository you publish to and download from, is run by Ruby Central, the same organisation that administers grant-funded work for improvements to the project. Support is asked in two directions: sponsoring individual contributors through the repository's own contributor graph, and supporting Ruby Central by attending or sponsoring a RubyConf, or by joining as a supporting member. So the funding path is split between the people who wrote the code and the organisation that runs the service, which is an unusual arrangement for a package manager and explains why the readme bothers to explain it. Bugs go to the issue tracker on the hosting platform, and Bundler-specific known issues have their own compatibility page.

Editorial conclusion

RubyGems is not a choice you make for a Ruby project, it is the layer everything else assumes, so the useful question is how to keep it current rather than whether to adopt it. The answer is the system update command, which is also why the upgrading document is linked from the readme rather than buried: a self-updating package manager is unusual and worth understanding before you rely on it. Two things to check before you run it. Where Ruby itself came from, because the readme is explicit that an operating system package is not a recommended install and that a version manager is the better route, and that if you keep the system version you should upgrade only through the same package manager and ignore every other instruction. And which Bundler you have, since it shares a version number with RubyGems and is developed in the same repository, so a known Bundler problem is documented on the same compatibility page as RubyGems behaviour.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. ruby/rubygems on GitHub