Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Readme changes

  • Loading branch information...
commit 1e19833de6ac0a8351850352084d288c4c4e3fa6 1 parent 2cf2da2
@dazuma authored
Showing with 14 additions and 11 deletions.
  1. +14 −11 README.rdoc
View
25 README.rdoc
@@ -8,6 +8,7 @@ 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:
@@ -15,21 +16,23 @@ need to worry about Ruby VM compatibility, will do something like:
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
@@ -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

0 comments on commit 1e19833

Please sign in to comment.
Something went wrong with that request. Please try again.