Purpose of Ruby 1.9?

[Rados³aw Bu³at]

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.

 

[tho_mica_l]

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.

 

[Wolfgang Nádasi-Donner]

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

 

[Windham, Kristopher R.]

in the Desktop reference by Matz, printed in 2002,
he says ..
"Developmental releases of Ruby always have an odd minor revision =20
number such as 1.5 or 1.7.
Once a developmental release is stable and finalized, it's then =20
"promoted" to a stable release. Stable releases always have an even =20
minor revision number such as 2.0 or3.2. Therefore, releases with =20
even subversion numbers are stable releases. Releases with odd =20
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 =20
else.

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

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 =20
development,
2.0 stable etc) I've read dissenting opinions of it.

--=20
Regards,
Luiz Vitor Martinez Cardoso [Grabber].
(11) 8187-8662

rubz.org - engineer student at maua.br

 

[Rick DeNatale]

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.

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.

 

[Dave Thomas]

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

 

[Rick DeNatale]

Me too:

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

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.

 

[Rados³aw Bu³at]

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

 

[botp]

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

 

[Xavier Noria]

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

 

[M. Edward (Ed) Borasky]

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

Well ... *after* it works on RSpec, rcov, flog, heckle, ZenTest, and all
of Ryan Davis' wonderful tools, sure, go ahead and fix Rails.

 

[Frederick Cheung]

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

 

[Rick DeNatale]

Well ... *after* it works on RSpec, rcov, flog, heckle, ZenTest, and all
of Ryan Davis' wonderful tools, sure, go ahead and fix Rails.

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.

 

[Windham, Kristopher R.]

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

 

[Luis Lavena]

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.

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.

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 Lavena

 

[Wolfgang Nádasi-Donner]

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

 

[M. Edward (Ed) Borasky]

Well ... *after* it works on RSpec, rcov, flog, heckle, ZenTest, and all
of Ryan Davis' wonderful tools, sure, go ahead and fix Rails.

[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.

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 ...)

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.

 

[Marc Heiler]

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!

 

[Rick DeNatale]

=begin translation
For now, we'll focus on improving 1.9. Bugs are certain to be found,
and there is still lots to do. So, I don't think there is any need to
create a 1.9 branch for now. Even if we do branch, we'll have to apply
fixes to both (trunk and branch), which is a doubling of required
effort, so just tagging should be sufficient.

Here's a possible plan for the next step:

* Release 1.9.1 sometime during the first half of 2008 (decide later
- perhaps April?)
* In order to drive development, make intermediate releases regularly
with short (one month?) intervals with the version fixed at 1.9.0
(releases every 29th?)

So I guess this means that version 1.9.0 will change at the end of
each month??? until 1.9.1 is released maybe in April.

If this is the case, I'm not sure just what changed when 1.9.0 was
released on the 25th.

I'm a bit confused.

 

[Wolfgang Nádasi-Donner]

* In order to drive development, make intermediate releases regularly
with short (one month?) intervals with the version fixed at 1.9.0
(releases every 29th?)

This may produce more confusion than help. There are a lot of things to
test and evaluate in Ruby 1.9.0, which takes time.

We now have a baseline for testing, which can be referenced in problem
reports. If there is a report area (http://rubyforge.org/projects/ruby/
???) everybody can see if a problem is already reported, and we can
follow the state of the report.

To plan a much more stable release Ruby 1.9.1 for April or so makes
sense, but to have monthly new Ruby 1.9.0 - what is principal the
difference to nightly snapshots?

Wolfgang Nádasi-Donner