Skip to content

Commit

Permalink
Readme changes
Browse files Browse the repository at this point in the history
  • Loading branch information
dazuma committed Nov 19, 2009
1 parent 2cf2da2 commit 1e19833
Showing 1 changed file with 14 additions and 11 deletions.
25 changes: 14 additions & 11 deletions README.rdoc
Original file line number Diff line number Diff line change
Expand Up @@ -8,28 +8,31 @@ numbers in the wide variety of versioning schemes in use.

Let's be honest. Version numbers are not easy to deal with, and very
seldom seem to be done right.

Imagine the common case of testing the Ruby version. Most of us, if we
need to worry about Ruby VM compatibility, will do something like:

do_something if RUBY_VERSION >= "1.8.7"

Treating the version number as a string works well enough, until it
doesn't. The above code will do the right thing for Ruby 1.8.6, 1.8.7,
1.8.8, and 1.9.1. But it will fail if the version is "1.8.10".
1.8.8, and 1.9.1. But it will fail if the version is "1.8.10" or "1.10".
And properly interpreting "prerelease" version syntax such as
"1.9.2-preview1"? Forget it.

There are a few version number classes out there that do better than
treating version numbers as plain strings. One well-known class is
Gem::Version, part of rubygems. This class separates the version into
fields and lets you manipulate and compare version numbers more robustly.
It provides limited support for "prerelease" versions through using
string-valued fields as a bit of a hack. However, it's still a little
clumsy. A prerelease version has to be represented like this: "1.9.2.b.1"
or "1.9.2.preview.2". Wouldn't it be nice to be able to parse more typical
version number formats such as "1.9.2b1" and "1.9.2 preview-2"? Wouldn't
treating version numbers as plain strings. One example is Gem::Version,
part of the RubyGems package. This class separates the version into fields
and lets you manipulate and compare version numbers more robustly. It even
provides limited support for "prerelease" versions through using string-
valued fields-- although it's a hack, and a bit of a clumsy one at that. A
prerelease version has to be represented like this: "1.9.2.b.1" or
"1.9.2.preview.2". Wouldn't it be nice to be able to parse more typical
version number formats such as "1.9.2b1" and "1.9.2-preview2"? Wouldn't
it be nice for a version like "1.9.2b1" to _understand_ that it's a "beta"
version and behave accordingly?

With Versionomy, you can!
With Versionomy, you can do all this and more.

=== Some examples

Expand All @@ -53,7 +56,7 @@ With Versionomy, you can!
v2 > v1 # => true
v2.to_s # => '1.4a3'

# Another parsing example.
# Version numbers are semantically self-adjusting.
v3 = Versionomy.parse('1.4.0b2')
v3.major # => 1
v3.minor # => 4
Expand Down

0 comments on commit 1e19833

Please sign in to comment.