Purpose of Ruby 1.9?

Ruby
1

First of all I want to thank Matz and Ko1 for yours great work! I
can’t say how much thankful I am for Ruby language.

My question is generally to Matz, Ko1 or other Ruby core maintainers.
We have Ruby 1.9 already released. Matz says that it’s not stable as
he expected, so it requires some work to become stable. But what
intentions are for Ruby 1.9.x? Is it released mainly for developers
and programmers which are very close to language (language, gem
maintainers) or it’s regular release for production usage? Does Ruby
follow unix style for labeling versions? (1.8 stable, 1.9 development,
2.0 stable etc) I’ve read dissenting opinions of it.

2

You are asking very usefull questions! Well… we need wait to someone
answer :wink:
Regards,
Luiz Vitor.

On Dec 26, 2007 6:50 PM, RadosÅ‚aw BuÅ‚at [email protected] wrote:

2.0 stable etc) I’ve read dissenting opinions of it.

–
Regards,
Luiz Vitor Martinez C. [Grabber].
(11) 8187-8662

rubz.org - engineer student at maua.br

3

Does Ruby
follow unix style for labeling versions? (1.8 stable, 1.9 development,
2.0 stable etc) I’ve read dissenting opinions of it.

IIRC this was true for 1.7. I think the “stable” version after 1.6 was
1.8.

4

tho_mica_l wrote:

Does Ruby
follow unix style for labeling versions? (1.8 stable, 1.9 development,
2.0 stable etc) I’ve read dissenting opinions of it.

IIRC this was true for 1.7. I think the “stable” version after 1.6 was
1.8.

I’m somehow surprised, because it was named since a long time what is
behind Ruby 1.9.

  1. Starting with planned Ruby 1.9.1 Ruby will not follow the even-odd
    number scheme, that was followed before. Ruby 1.9.n (n>=1) will be a
    stable version, planned for production usage.

  2. Ruby 1.9.n (n>=1) contains the ideas from Ruby 2, that are actual
    feasible.

  3. Work on Ruby 2 didn’t start now.

  4. Ruby 1.9.0 was released instead of the planned Ruby 1.9.1, because
    the trunk was not as stable on 25.12. as everybody wants. It is not
    intended as a production version.

  5. Ruby 1.9.0 is stable in respect to features, and is from this
    viewpoint a reference inplementation, which can be used by developers.

This is what how I understand all the posts an conference videos on the
last year. I hope it is complete an correct (Mats?)

Wolfgang Nádasi-Donner

5

in the Desktop reference by Matz, printed in 2002,
he says …
“Developmental releases of Ruby always have an odd minor revision
number such as 1.5 or 1.7.
Once a developmental release is stable and finalized, it’s then
“promoted” to a stable release. Stable releases always have an even
minor revision number such as 2.0 or3.2. Therefore, releases with
even subversion numbers are stable releases. Releases with odd
subversion numbers are developmental versions…”
I assume this is still the case.
Do not ever use a developmental release for production.
As far as intentions for 1.9.x, I will leave that answer to some one
else.

6

On Dec 26, 2007 5:39 PM, Windham, Kristopher R. [email protected]
wrote:

Do not ever use a developmental release for production.
As far as intentions for 1.9.x, I will leave that answer to some one
else.

Matz announced a change to this versioning policy a few months ago on
the ruby core forum.

1.9 which has been in a state of definitional flux for over a year,
with experimental features being added to the language, then changed
or dropped, was to have become functionally stable yesterday. As I
understand it the intent was that yesterday’s release was to have been
1.9.1 instead of 1.9.0, which would have signalled this stability. I
think that the language definition for Ruby 1.9 is now pretty well
fixed, although Matz has reserved the right to make changes in the
case that a major mistake is found.

At the same time he made the remarks about the versioning changes,
Matz indicated that 1.9.1 would still not be production ready and that
the implementation would still be evolving over the next several
months. The intention, as I read it, was to put a stake in the ground
with a definitionally stable 1.9 so that the developers of important
ruby code like Rails, etc. could start developing versions compatible
with the new language.

I’m a little concerned that some folks are jumping on 1.9 as an
immediate replacement for Ruby 1.8, which it isn’t.

–
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

7

Hi,

In message “Re: Purpose of Ruby 1.9?”
on Thu, 27 Dec 2007 07:29:41 +0900, Wolfgang N1dasi-onner
[email protected] writes:

|I’m somehow surprised, because it was named since a long time what is
|behind Ruby 1.9.
|
|1) Starting with planned Ruby 1.9.1 Ruby will not follow the even-odd
|number scheme, that was followed before. Ruby 1.9.n (n>=1) will be a
|stable version, planned for production usage.
|
|2) Ruby 1.9.n (n>=1) contains the ideas from Ruby 2, that are actual
|feasible.
|
|3) Work on Ruby 2 didn’t start now.
|
|4) Ruby 1.9.0 was released instead of the planned Ruby 1.9.1, because
|the trunk was not as stable on 25.12. as everybody wants. It is not
|intended as a production version.
|
|5) Ruby 1.9.0 is stable in respect to features, and is from this
|viewpoint a reference inplementation, which can be used by developers.
|
|This is what how I understand all the posts an conference videos on the
|last year. I hope it is complete an correct (Mats?)
|
|Wolfgang Nádasi-Donner

Yes, it’s complete and correct.

To answer the original poster’s question, the purpose of Ruby 1.9.0
release announcement on the Christmas day was development driving. We
had tremendous improvements in last few weeks which cannot be achieved
without the goal. Otherwise we had to wait a few more years to get
production stable 1.9 version. Thank you for everyone cooperated.

          matz.
8

On Dec 26, 2007, at 4:53 PM, Rick DeNatale wrote:

I’m a little concerned that some folks are jumping on 1.9 as an
immediate replacement for Ruby 1.8, which it isn’t.

Me too:

http://pragdave.blogs.pragprog.com/pragdave/2007/12/ruby-19right-fo.html

Dave

9

On Dec 26, 2007 6:11 PM, Dave T. [email protected] wrote:

Dave
I just answered a post from someone on the Textmate forum who
installed Ruby1.9 as ruby. Now he gets a syntax error inside textmate
when he tries to run a ruby program, since Textmate uses ruby
internally, and some of that code ran into one of the syntax
incompatibilities.

–
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

10

Matz and others - thanks for answers. It’s great news for me. I’m
starting exploring new Ruby features. I love this language! :slight_smile:

11

On Dec 27, 2007 7:11 AM, Dave T. [email protected] wrote:

On Dec 26, 2007, at 4:53 PM, Rick DeNatale wrote:

I’m a little concerned that some folks are jumping on 1.9 as an
immediate replacement for Ruby 1.8, which it isn’t.
Me too:
http://pragdave.blogs.pragprog.com/pragdave/2007/12/ruby-19right-fo.html

will it be “safe” to say that the baptism of fire for ruby1.9 is
lettting it run/support rails 2.0.2 without errors?

kind regards -botp

12

On Dec 27, 2007, at 8:53 AM, botp wrote:

On Dec 27, 2007 7:11 AM, Dave T. [email protected] wrote:

On Dec 26, 2007, at 4:53 PM, Rick DeNatale wrote:

I’m a little concerned that some folks are jumping on 1.9 as an
immediate replacement for Ruby 1.8, which it isn’t.
Me too:
http://pragdave.blogs.pragprog.com/pragdave/2007/12/ruby-19right-fo.html

will it be “safe” to say that the baptism of fire for ruby1.9 is
lettting it run/support rails 2.0.2 without errors?

Wouldn’t that be a Rails goal?

The reason Rails does not run on 1.9 are to my knowledge
incompatibilities, it is not due to 1.9 not being production-ready.
People have been sending compatibility patches to Rails, but work
remains to be done.

– fxn

13

botp wrote:

kind regards -botp

Well … after it works on RSpec, rcov, flog, heckle, ZenTest, and all
of Ryan D.’ wonderful tools, sure, go ahead and fix Rails. :slight_smile:

14

On 27 Dec 2007, at 08:45, Xavier N. wrote:

lettting it run/support rails 2.0.2 without errors?

Wouldn’t that be a Rails goal?

The reason Rails does not run on 1.9 are to my knowledge
incompatibilities, it is not due to 1.9 not being production-ready.
People have been sending compatibility patches to Rails, but work
remains to be done.

I know of at least one bug in 1.9 that breaks certain bits of rails
(http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/14379
). But it’s true that a lot of stuff is just different, that’s
expected. Ruby 1.9 is not in the general case a drop-in replacement
for 1.8

Fred

15

I don’t believe that can happen…
Ruby programmers like to be on the cutting edge, it seems…

16

On Dec 27, 2007 4:28 AM, M. Edward (Ed) Borasky [email protected]
wrote:

lettting it run/support rails 2.0.2 without errors?

kind regards -botp

Well … after it works on RSpec, rcov, flog, heckle, ZenTest, and all
of Ryan D.’ wonderful tools, sure, go ahead and fix Rails. :slight_smile:

Keep in mind that Ruby 1.9 is really a new language, Matz and co
decided to release it as a way of driving towards Ruby 2.0 whose
version number would more clearly indicate this, but there are changes
in 1.9, which are deliberately incompatible with Ruby 1.8. Matz has
spent the past few months backing out some of the more radical
experimental changes, but there’s no guarantee of backward
compatibility.

So the work to be done is on both sides. Yes, there are, known, and
unknown bugs in Ruby 1.9 which will be worked out by the core team,
but on the other side, work needs to be done by all those tools and
frameworks to ‘port’ to the new language. The new and removed language
features of 1.9 are not likely to change unless something comes up
which indicates a major mistake in the definition of Ruby 1.9.

It’s a community project.

On the whole, I think that this is a good thing, Ruby 1.9 gives the
community a stepping stone on the path to Ruby 2.0. I’d hate to see
Ruby suffer the fate of, say PHP, which has had some difficulties in
getting it’s community to move to the latest version of the language.

Some of us have been keeping an eye on the evolution of 1.9 for some
time before 1.9.0 we’ve been the scouts, with 1.9.0 we’re starting to
see more early adopters, or pioneers, start the journey to Ruby 2.0.
The danger is unwitting pioneers won’t have gotten the message about
the role of 1.9 in relation to 1.8 (and 2.0) and will load up their
Conestoga wagons without realizing the real possibility of getting
arrows in their back.

What concerns me is that I’m seeing postings from folks, not only
here, but places like the Textmate mailing list, who have installed
Ruby 1.9 from source, and found that existing code using, and
expecting the ruby command to map to Ruby 1.8 is breaking.

I posted a suggestion to ruby-core that perhaps the Ruby 1.9 tarball
should be set up so that BY DEFAULT, it installs as ruby1.9 instead of
ruby, so that unwitting installers don’t get their Ruby1.8
installation replaced by default.

–
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

17

On Dec 27, 12:04 pm, Rick DeNatale [email protected] wrote:

Keep in mind that Ruby 1.9 is really a new language, Matz and co
decided to release it as a way of driving towards Ruby 2.0 whose
version number would more clearly indicate this, but there are changes
in 1.9, which are deliberately incompatible with Ruby 1.8. Matz has
spent the past few months backing out some of the more radical
experimental changes, but there’s no guarantee of backward
compatibility.

Exactly, 1.9.0 was labeled a “development” release, not a stable, not
the replacement for 1.8 from day zero, will take longer to achieve
that goal.

Ruby 1.9 from source, and found that existing code using, and
expecting the ruby command to map to Ruby 1.8 is breaking.

The problem is that these users don’t read things, don’t research a
bit before start playing with loaded guns, they didn’t read the
development release label matz put on his announcement.

I posted a suggestion to ruby-core that perhaps the Ruby 1.9 tarball
should be set up so that BY DEFAULT, it installs as ruby1.9 instead of
ruby, so that unwitting installers don’t get their Ruby1.8
installation replaced by default.

Users experimenting with installation from source should be aware of
these risks. Is not Ruby responsibility to “babysit” all the users and
avoid they shoot their foot.

What you requested will also require a “new” release of 1.9.0-0, (note
the zero of patchlevel), and I think is too early to do it (the
complexity and because matz, ko1 and others need to relax a bit).

Luis L.

18

Rick DeNatale wrote:

On Dec 27, 2007 4:28 AM, M. Edward (Ed) Borasky [email protected] wrote:

Well … after it works on RSpec, rcov, flog, heckle, ZenTest, and all
of Ryan D.’ wonderful tools, sure, go ahead and fix Rails. :slight_smile:

[snip]

On the whole, I think that this is a good thing, Ruby 1.9 gives the
community a stepping stone on the path to Ruby 2.0. I’d hate to see
Ruby suffer the fate of, say PHP, which has had some difficulties in
getting it’s community to move to the latest version of the language.

Or Perl 6, which apparently will never be adopted. :slight_smile:

Some of us have been keeping an eye on the evolution of 1.9 for some
time before 1.9.0 we’ve been the scouts, with 1.9.0 we’re starting to
see more early adopters, or pioneers, start the journey to Ruby 2.0.
The danger is unwitting pioneers won’t have gotten the message about
the role of 1.9 in relation to 1.8 (and 2.0) and will load up their
Conestoga wagons without realizing the real possibility of getting
arrows in their back.

Well, sure … I haven’t done much with Ruby 1.9 outside of performance
testing till now because:

a. Performance testing is my thing, and

b. 99 44/100 of the code I personally write will work in all of the
current implementations.

The context of my post was:

a. I don’t really care whether Rails ever runs with 1.9, or even 2.0. It
runs with MRI, it runs with jRuby, and a moderate amount of tweaking can
get either of them past the “throw hardware at it” method of performance
tuning. People are earning a decent living as Rails programmers, and
they don’t need 1.9 any more than they need to upgrade from RHEL 4 to
RHEL 5 if RHEL 4 is working for them.

b. What I do care about is the other thing Ruby is really good at –
behavior/test driven development, meta-programming, domain-specific
languages, pragmatic programming, continuous integration, etc. And the
people who built these tools are the very pioneers we “settlers” are
counting on to make Ruby 1.9 and Ruby 2.0 successful in this domain. So
anything we can do to make their job easier is worth doing. (Like
going back to MinGW on Windows …) :wink:

What concerns me is that I’m seeing postings from folks, not only
here, but places like the Textmate mailing list, who have installed
Ruby 1.9 from source, and found that existing code using, and
expecting the ruby command to map to Ruby 1.8 is breaking.

I posted a suggestion to ruby-core that perhaps the Ruby 1.9 tarball
should be set up so that BY DEFAULT, it installs as ruby1.9 instead of
ruby, so that unwitting installers don’t get their Ruby1.8
installation replaced by default.

Yeah, that makes sense, given that it is a “development” release. It
would also make the job of Linux distro package management systems a lot
easier, so we’d see Ruby 1.9 show up in Fedora, Debian/Ubuntu and Gentoo
a lot sooner. Right now, they have limited manpower and can’t cope with
all the extra work associated with having two versions of Ruby, even
though they all have provisions for it.

19

The problem is that these users don’t read things

I dont think that is a huge problem. Just point them to the URL of this
thread/mail where someone stated that “it is a new language”, which
kinda says all there is to be said about it in a very concise manner.
It’s more a … paradigm shift than a slow gradual change with baby
steps! :slight_smile:

20

Rick Denatale wrote:

I posted a suggestion to ruby-core that perhaps the Ruby 1.9 tarball
should be set up so that BY DEFAULT, it installs as ruby1.9 instead of
ruby, so that unwitting installers don’t get their Ruby1.8
installation replaced by default.

I don’t think so. Add a YOU-SHOULD-REALLY.README file which strongly
recommends to use “–prefix” and “–programm-suffix” in “configure”.

Wolfgang Nádasi-Donner