On Wed, 8 Apr 2009, Jason G. wrote:
BTW, 4.1.9 followed 4.1.1 because I was trying to be cute. RedCloth 4.1.9 was
the first release to be compatible with Ruby 1.9. Get it? In the end,
though, it was a mistake. I’ve wanted to release another 4.1.x but I don’t
want to do 4.1.10 because then you can’t compare version numbers as strings.
Are we going to be stuck with this idea forever? We ran into this
when the successor to Ruby 1.8 could not be Ruby 1.10, breaking the
odd/even as unstable/stable releases pattern. Version numbers are
not strings, but even if they are (a) they should be parsed (Is
Debian version “Woody”.to_i.zero? ?), and (b):
http://rubyforge.org/projects/natcmp/
Try searching for “natural order string comparison”.
I really think that Ruby needs a native class for versions.
That way it would not be a subclass of String.
I should have used Comparable for this, written about 7 months into
using Ruby:
http://www.cse.dmu.ac.uk/~hgs/ruby/revision.rb
My point being this is not something doable by only the advanced
programmer, even if this effort could do with improvement.
The other reason Ruby didn’t have 1.10 as a stable release was C code
checking based on single bytes per {major, minor, teeny} (or whatever
you call the third one).
Do you have any evidence for people comparing these (Redcloth)
version numbers as if they were strings? If nobody does, then why
worry about it? The clue is in the nomenclature: “version numbers”.
Not to mention the fact that it’s just plain confusing So, expect the next
I don’t see that as confusing: it’s one of those things that is already
tradition in this field less than 100 years old.
version to be 4.2.0.
Hugh