versioning - How do version numbers work for MRI Ruby?

Question

A recent question, "What happened with Ruby 1.9.2?", made me wonder about version numbers for MRI Ruby mean.

The scheme MRI Ruby uses differs from that of semver.org.

How does versioning work in MRI Ruby, and what do the major (1), minor (9), teeny (3) and patchlevel (448) values mean in ruby 1.9.3p448? For example, what kind of changes are allowed in an increase in patchlevel, and what kind of changes are allowed in an increase of teeny?

Answer 1

(Here the terms differ from the classic semver.org where 2.0.0 is composed of MAJOR.MINOR.PATCH: The ruby scheme, as illustrated in version.h or test_gem.rb, is more V2.0.0pxxx, as in MAJOR.MINOR.TEENY.PATCHLEVEL)

• Major seems to be reserved for language changes, as illustrated by Ruby2.0.0 Change Logs.
• Minor used to have a different meaning than today, from the article on 1.9 release (December 2007):

Previously, a version number for Ruby with an odd minor version number signified an experimental version. So Ruby 1.7 was experimental, while Ruby 1.8 was a production version.
The Ruby core team has changed this so that, with the advent of Ruby 1.9.0, Ruby 1.9 is no longer considered experimental, although it may be a while before the implementation becomes ready for production use

Today, a minor version contains semantic differences:

On the other hand, Ruby 1.9 is not completely backward compatible with Ruby 1.8. Some of the semantics have changed. For example, block arguments are now local to the block, and there are subtle changes to block semantics.The changes mean that many existing Ruby programs will need some amount of conversion to take advantage of Ruby 1.9.

• teeny (like 1.9.2) adds new features

• patchlevel is more about a build number, adding internal fixes, security fixes, promoting a ruby version to "production level" (as that was the case for 1.9.2-p290)