README.md

VersionGem

---

Alternatives

This gem has a very niche purpose, which is:

1. providing introspection of a Version module based on a VERSION constant string within it,
2. while not interfering with gemspec parsing where the VERSION string is traditionally used,
3. allowing 100% test coverage of Ruby code, including the Version module.

As proof in the pudding, this gem achieves 100% test coverage for lines and branches, all 77 and 2 of them, respectively; coverage enabled in part by patterns from this library. You can make it happen for your library too!

If this isn't precisely your use case you may be better off looking at versionaire, a wonderful, performant, well-maintained, gem from the Alchemists, or version_sorter from GitHub.

For more discussion about this see issue #2

Still here?

Give your next library an introspectable Version module without breaking your Gemspec.

MyLib::Version.to_s # => "1.2.3.rc3"
MyLib::Version.major # => 1
MyLib::Version.minor # => 2
MyLib::Version.patch # => 3
MyLib::Version.pre # => "rc3"
MyLib::Version.to_a # => [1, 2, 3, "rc3"]
MyLib::Version.to_h # => { major: 1, minor: 2, patch: 3, pre: "rc3" }

This library was extracted from the gem oauth2.

This gem has no runtime dependencies.

Info you can shake a stick at

Tokens to Remember
Works with JRuby
Works with Truffle Ruby
Works with MRI Ruby 3
Works with MRI Ruby 2
Source
Documentation
Compliance
Expert 1:1 Support	or
Enterprise Support	💡Subscribe for support guarantees covering all FLOSS dependencies! 💡Tidelift is part of Sonar! 💡Tidelift pays maintainers to maintain the software you depend on! 📊@Pointy Haired Boss: An enterprise support subscription is "never gonna let you down", and supports open source maintainers!
Comrade BDFL 🎖️
... 💖

Installation

Install the gem and add to the application's Gemfile by executing:

$ bundle add version_gem

If bundler is not being used to manage dependencies, install the gem by executing:

$ gem install version_gem

Usage

In the standard bundle gem my_lib code you get the following in lib/my_lib/version.rb:

module MyLib
  VERSION = "0.1.0"
end

Change it to a nested Version namespace (the one implied by the path => namespace convention):

module MyLib
  module Version
    VERSION = "0.1.0"
  end
end

Now add the following near the top of the file the manages requiring external libraries. Using the same example of bundle gem my_lib, this would be lib/my_lib.rb.

require "version_gem"

Then, add the following wherever you want in the same file (recommend the bottom).

MyLib::Version.class_eval do
  extend VersionGem::Basic
end

And now you have some version introspection methods available:

MyLib::Version.to_s # => "0.1.0"
MyLib::Version.major # => 0
MyLib::Version.minor # => 1
MyLib::Version.patch # => 0
MyLib::Version.pre # => ""
MyLib::Version.to_a # => [0, 1, 0]
MyLib::Version.to_h # => { major: 0, minor: 1, patch: 0, pre: "" }

Side benefit #1

You can reference the version from your gemspec, keeping the version string DRY, and still get accurate code coverage!

# Get the GEMFILE_VERSION without *require* "my_gem/version", for code coverage accuracy
# See: https://github.com/simplecov-ruby/simplecov/issues/557#issuecomment-2630782358
# Kernel.load because load is overloaded in RubyGems during gemspec evaluation
Kernel.load("lib/my_gem/version.rb")
gem_version = MyGem::Version::VERSION
MyGem::Version.send(:remove_const, :VERSION)

Gem::Specification.new do |spec|
  # ...
  spec.version = gem_version
end

Side benefit #2

Your version.rb file now abides the Ruby convention of directory / path matching the namespace / class!

Zietwerk

The pattern of version.rb breaking the ruby convention of directory / path matching the namespace / class is so entrenched that the zeitwerk library has a special carve-out for it. 🥺 RubyGems using this "bad is actually good" pattern are encouraged to use Zeitwerk.for_gem.

Do not do that ^ if you use this gem.

Simple Zeitwerk Example

Create a gem like this (keeping with the MyLib theme):

bundle gem my_lib

Then following the usage instructions above, you edit your primary namespace file @ lib/my_lib.rb, but inject the Zeitwerk loader.

# frozen_string_literal: true

require_relative "my_lib/version"

module MyLib
  class Error < StandardError; end
  # Your code goes here...
end

loader = Zeitwerk::Loader.new
loader.tag = File.basename(__FILE__, ".rb")
loader.push_dir("lib/my_lib", namespace: MyLib)
loader.setup # ready!
loader.eager_load(force: true) # optional!

MyLib::Version.class_eval do
  extend VersionGem::Basic
end

Complex Zeitwerk Example

Maybe you would like to contribute one?

Query Ruby Version (as of version 1.1.2)

In Continuous Integration environments for libraries that run against many versions of Ruby, I often need to configure things discretely per Ruby version, and doing so forced me to repeat a significant amount of boilerplate code across each project.

Thus VersionGem::Ruby was born. It has the two optimized methods I always need:

engine = "ruby"
version = "2.7.7"
gte_minimum_version?(version, engine)  # Is the current version of Ruby greater than or equal to some minimum?

major = 3
minor = 2
actual_minor_version?(major, minor, engine) # Is the current version of Ruby precisely a specific minor version of Ruby?

Version::Ruby is not loaded by default. If you want to use it, you must require it as:

require "version_gem/ruby"

Normally I do this in my spec/spec_helper.rb, and/or .simplecov files. Occasionally in my Rakefile.

Caveat

This design keeps your version.rb file compatible with the way gemspec files use them. This means that the introspection is not available within the gemspec. The enhancement from this gem is only available at runtime.

RSpec Matchers

In spec_helper.rb:

require "version_gem/rspec"

Then you can write a test like:

RSpec.describe(MyLib::Version) do
  it_behaves_like "a Version module", described_class
end

# Or, if you want to write your own, here is the á la carte menu:
RSpec.describe(MyLib::Version) do
  it "is a Version module" do
    expect(described_class).is_a?(Module)
    expect(described_class).to(have_version_constant)
    expect(described_class).to(have_version_as_string)
    expect(described_class.to_s).to(be_a(String))
    expect(described_class).to(have_major_as_integer)
    expect(described_class).to(have_minor_as_integer)
    expect(described_class).to(have_patch_as_integer)
    expect(described_class).to(have_pre_as_nil_or_string)
    expect(described_class.to_h.keys).to(match_array(%i[major minor patch pre]))
    expect(described_class.to_a).to(be_a(Array))
  end
end

🔐 Security

See SECURITY.md.

🤝 Contributing

If you need some ideas of where to help, you could work on adding more code coverage, or if it is already 💯 (see below) then check issues, or PRs, or use the gem and think about how it could be better.

We so if you make changes, remember to update it.

See CONTRIBUTING.md for more detailed instructions.

Code Coverage

🪇 Code of Conduct

Everyone interacting in this project's codebases, issue trackers, chat rooms and mailing lists is expected to follow the .

🌈 Contributors

Made with contributors-img.

Also see GitLab Contributors: https://gitlab.com/oauth-xx/version_gem/-/graphs/main

⭐️ Star History

📌 Versioning

This Library adheres to . Violations of this scheme should be reported as bugs. Specifically, if a minor or patch version is released that breaks backward compatibility, a new version should be immediately released that restores compatibility. Breaking changes to the public API will only be introduced with new major versions.

📌 Is "Platform Support" part of the public API?

Yes. But I'm obligated to include notes...

SemVer should, but doesn't explicitly, say that dropping support for specific Platforms is a breaking change to an API. It is obvious to many, but not all, and since the spec is silent, the bike shedding is endless.

dropping support for a platform is both obviously and objectively a breaking change

• Jordan Harband (@ljharb) in SemVer issue 716

To get a better understanding of how SemVer is intended to work over a project's lifetime, read this article from the creator of SemVer:

• "Major Version Numbers are Not Sacred"

As a result of this policy, and the interpretive lens used by the maintainer, you can (and should) specify a dependency on these libraries using the Pessimistic Version Constraint with two digits of precision.

For example:

spec.add_dependency("version_gem", "~> 1.1")

See CHANGELOG.md for list of releases.

📄 License

The gem is available as open source under the terms of the MIT License . See LICENSE.txt for the official Copyright Notice.

© Copyright

Copyright (c) 2022 - 2025 Peter H. Boling, RailsBling.com

🤑 One more thing

You made it to the bottom of the page, so perhaps you'll indulge me for another 20 seconds. I maintain many dozens of gems, including this one, because I want Ruby to be a great place for people to solve problems, big and small. Please consider supporting my efforts via the giant yellow link below, or one of the others at the head of this README.