Determining whether the running ruby is outdated?

[Lars Olsson]

Hi,

I'm writing a small utility that shows information on the currently
running ruby environment. One part of the utility checks whether any
gems is outdated, but I also want to check if the ruby interpreter
itself is outdated. Getting the currently installed version is simple,
but getting a list of released ruby versions seems a bit trickier. I'm
mainly interested in *stable* source versions, but I don't mind if my
utility lists development and rc versions as well.

Does anyone know a good way of checking this? My first try was to use
the ruby github mirror to fetch available tags. Then I tried using
svn.ruby-lang.org to get the same information, but neither of those
gave me the information I wanted in a simple way.

Any suggestions on how to solve this?

/lasso

 

[Roger Pack]

Hi,

I'm writing a small utility that shows information on the currently
running ruby environment. One part of the utility checks whether any
gems is outdated, but I also want to check if the ruby interpreter
itself is outdated. Getting the currently installed version is simple,
but getting a list of released ruby versions seems a bit trickier. I'm
mainly interested in *stable* source versions, but I don't mind if my
utility lists development and rc versions as well.
Any suggestions on how to solve this?

Possibly parse this list:

http://ftp.ruby-lang.org/pub/ruby/1.9/

et al.
-r

 

[Dan Rathbun]

I'm writing a small utility that shows information on the currently
running ruby environment. One part of the utility checks whether any
gems is outdated, but I also want to check if the ruby interpreter
... Getting the currently installed version is simple,
but getting a list of released ruby versions seems a bit trickier. I'm
mainly interested in *stable* source versions, but I don't mind if my
utility lists development and rc versions as well.

I just went thru ALL the 1.8.x i386-mswin32 releases compiling a list,
and did 1.9.1 also.

I did NOT do any previews, or release candidates, or 1.9.0 or 1.6.x

Any suggestions on how to solve this?

I had to spend 2 days downloading every package, extracting the
interpreter DLLs, a PITB.

The file is not done.. I'm missing a few dates.
I may also be missing a few patch_levels that were released for test,
but no precompiled package was released. (not likely anyone is running
them.)

I wrote a PureRuby Backport Patch for older versions, that adds newer
constants to older versions (<1.8.7), which you might like to use
(you'll get the idea when you read it; it can be condensed into smaller
code.)
It's attached here, and in the post you'll see other links where it's
available (rubyforge snippet library, etc.)
http://redmine.ruby-lang.org/issues/show/3665

.. some has suggested I add RUBY_ENGINE to all before 1.9.x (but I
haven't got to it yet.)

Attachments:
http://www.ruby-forum.com/attachment/4934/Ruby_Releases.txt

 

[Dan Rathbun]

.. some has suggested I add RUBY_ENGINE to all before 1.9.x (but I
haven't got to it yet.)

Here's the snippet for RUBY_ENGINE:

#
# RUBY_ENGINE was added sometime in the 1.9.x branch
#
if defined?(RUBY_ENGINE).nil?
RUBY_ENGINE = RUBY_VERSION.split('.')[0..1].join('.')
end

 

[Lars Olsson]

Possibly parse this list:

http://ftp.ruby-lang.org/pub/ruby/1.9/

et al.
-r

Thanks guys! I was hoping there was a simpler method than parsing
directory listings (say, like a text file) but if that's the way to go
then I'll just have to dig in.

/lasso

 

[Roger Pack]

Thanks guys! I was hoping there was a simpler method than parsing
directory listings (say, like a text file) but if that's the way to go
then I'll just have to dig in.

Yeah that's the general way people have done it in the past. You could
also screen scrape ruby-lang.org page I suppose...

 

[Roger Pack]

I wrote a PureRuby Backport Patch for older versions, that adds newer
constants to older versions (<1.8.7), which you might like to use
(you'll get the idea when you read it; it can be condensed into smaller
code.)
It's attached here, and in the post you'll see other links where it's
available (rubyforge snippet library, etc.)
http://redmine.ruby-lang.org/issues/show/3665

There's also a backports gem, if that helps at all.

 

[Dan Rathbun]

Thanks guys! I was hoping there was a simpler method than parsing
directory listings (say, like a text file) ...

I attached my TEXT FILE to my previous post Lars.

Look at the header, viz:

Re: Determining whether the running ruby is outdated?
Posted by Dan Rathbun (dan_rathbun) on 11.08.2010 02:38
Attachment: Ruby_Releases.txt (1,1 KB) <<<---------------<<<<<<

... or click this link:
http://www.ruby-forum.com/attachment/4934/Ruby_Releases.txt

... BUT be aware I have seen the release date vary in the minGW32 built
DLLs by a few days, from the "official" release date. I am not sure if
that also is reflected in the value of the RUBY_RELEASE_DATE constant
when running a minGW32 built interpreter.

You could ask Luis Lavena over at:
http://groups.google.com/group/rubyinstaller

 

[Lars Olsson]

I attached my TEXT FILE to my previous post Lars.

Look at the header, viz:

Re: Determining whether the running ruby is outdated?
Posted by Dan Rathbun (dan_rathbun) on 11.08.2010 02:38
Attachment: Ruby_Releases.txt (1,1 KB)  <<<---------------<<<<<<

.. or click this link:http://www.ruby-forum.com/attachment/4934/Ruby_Releases.txt

.. BUT be aware I have seen the release date vary in the minGW32 built
DLLs by a few days, from the "official" release date. I am not sure if
that also is reflected in the value of the RUBY_RELEASE_DATE constant
when running a minGW32 built interpreter.

You could ask Luis Lavena over at:http://groups.google.com/group/rubyinstaller

Sorry, I did not mean to ignore your solution. Will the file be
updated on regular intervals? Is the current location static or will
it change? Since my utility will have to rely on external resources it
is important to me that it will not break due to those external
resources changing location or containing old information.

/lasso

 

[Dan Rathbun]

Will the file be updated on regular intervals?

I will update it for my own use (as a reference to keep track
of what I have done etc., for my own applet.)

Is the current location static or will it change?

I dont know much about how the ruby-forum software works.

Since my utility will have to rely on external resources it
is important to me that it will not break due to those external
resources changing location or containing old information.

Hmmm... Luis Lavena is also involved with pik developement (which is a
Ruby Version Manager and Configurator,) for Windows. There is also RVM
(for Unix-like systems.)

Both of these utilities have a gem-like install capability. You would
think somewhere that there must be a "dictionary" so that these
utilities can find the 'rubies' (the term for a specific Ruby
cpu-platform-version-patchlevel package,) to install.

They may just be using RubyGems to read the ruby-lang.org gem
repository.

But anyway... I am not "on" the Ruby Core project team, the Ruby
Installer project team, etc. I just make a few suggestions from time to
time.

I have nothing against anyone taking what I've begun (cleaning it up,
changing format [JSON, CSV, PStore, etc.] and using it to create on
online 'official dictionary' of some kind.
I agree it should be somewhere like rubyforge.net or ruby-lang.org

 

[Dan Rathbun]

Lars, I found where the information is in each package.

It is in the version.h file (a C source header file.)

In the some of the older precompiled packages, a copy of this file, is
placed in the #{platform} subdir of the ruby/lib/ruby/#{engine}
directory.
In newer precompiled packages, it cannot find it and it may have been
replaced with rbconfig.rb

In the source packages, the file is in the source/#{ver-patchlevel} dir
of the source archives.
The problem with them is thay are all in compressed archives (tarballs
or zips,) so you cannot read them over the net.


Here's an example of what the version.h file looks like in the 1.8.7
branch.
http://svn.ruby-lang.org/repos/ruby/branches/ruby_1_8_7/version.h
This example is only the latest patch as this is the svn active
development repository. (The file will change at the next revision.)

 

[Florian Aßmann]

I did in IRB

`svn ls http://svn.ruby-lang.org/repos/ruby/tags`.split.grep(/\Av\d/)
.map { |d| `svn cat =
http://svn.ruby-lang.org/repos/ruby/tags/#{d}version.h` }

It took a while but I had alot of information.

Am 10.08.2010 um 11:25 schrieb Lars Olsson:

 

[Luis Lavena]

Lars, I found where the information is in each package.

It is in the version.h file (a C source header file.)

In the some of the older precompiled packages, a copy of this file, is
placed in the #{platform} subdir of the ruby/lib/ruby/#{engine}
directory.
In newer precompiled packages, it cannot find it and it may have been
replaced with rbconfig.rb

No, all versions of MRI (Matz Ruby Implementation) still stores
version information in a C header, not Ruby code.

In the source packages, the file is in the source/#{ver-patchlevel} dir
of the source archives.
The problem with them is thay are all in compressed archives (tarballs
or zips,) so you cannot read them over the net.

Yes, the only workaround is download, extract and find the file.

In RubyInstaller we know what we are looking for:

http://github.com/oneclick/rubyinstaller/blob/master/recipes/packager/inno.rake#L3-14
http://github.com/oneclick/rubyinstaller/blob/master/recipes/packager/inno.rake#L116

Do a Dir.glob and look for version.h

 

[Lars Olsson]

No, all versions of MRI (Matz Ruby Implementation) still stores
version information in a C header, not Ruby code.


Yes, the only workaround is download, extract and find the file.

In RubyInstaller we know what we are looking for:

http://github.com/oneclick/rubyinst...ck/rubyinstaller/blob/master/recipes/packager...

Do a Dir.glob and look for version.h

Thanks everybody for all of your suggestions. I finally decided that
the downloads available from ftp.ruby-lang.org provide me with the
information I need. Even though the information obtained cannot be
guaranteed to be accurate, the naming scheme on that site seems quite
stable.

If someone is interested the app is available on github:
http://github.com/lasso/random/raw/master/runtimeinfo.rb

And here are the results from my current irb session:

irb(main):001:0> load 'runtimeinfo.rb'
=> true
irb(main):002:0> puts
Lassoweb::Utils::RuntimeInfo.latest_ruby_versions
Latest stable version: 1.9.1-p430
Latest release candidate: 1.9.2-rc2
Latest preview: 1.9.2-preview3
=> nil

/lasso