Purpose of Ruby 1.9?
Radosław Bułat
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
> 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
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
--
Posted via http://www.ruby-forum.com/.
Windham, Kristopher R.
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.
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.
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
Dave Thomas
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
Yukihiro Matsumoto
In message "Re: Purpose of Ruby 1.9?"
on Thu, 27 Dec 2007 07:29:41 +0900, Wolfgang N1dasi-onner <ed.o...@wonado.de> 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.
Rick DeNatale
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
starting exploring new Ruby features. I love this language! :)
botp
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
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
of Ryan Davis' wonderful tools, sure, go ahead and fix Rails. :)
Frederick Cheung
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
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.
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".
M. Edward (Ed) Borasky
> On Dec 27, 2007 4:28 AM, M. Edward (Ed) Borasky <zn...@cesmail.net> wrote:
>> 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
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! :-)
Leonard Chin
On Dec 27, 2007 5:50 AM, Radosław Bułat <radek...@gmail.com> wrote:
> 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?
Here's a quick translation of the relevant parts of a mail from matz
to ruby-dev that are kind of relevant to this question.
reference: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/32794
=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?)
* Prepare documentation for migrating from 1.8 to 1.9 in parallel
What do you think?
= end
# Disclaimer: this is just a translation of part of a single mail from
matz in a thread of discussion. It is not an announcement.
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
Yukihiro Matsumoto
In message "Re: Purpose of Ruby 1.9?"
on Fri, 28 Dec 2007 23:57:10 +0900, "Rick DeNatale" <rick.d...@gmail.com> writes:
|> - 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.
They will be bug fix versions. The spec will not be changed. If
changed, they were spec bugs.
matz.
Giles Bowkett
> 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.
Given the colossal numbers of clueless posts by Rails newbs that
happen all over the Web, I think that this is an extreeeeeeeeeeemely
good idea.
--
Giles Bowkett
Podcast: http://hollywoodgrit.blogspot.com
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com
Rick DeNatale
But will they all be version 1.9.0? What's the meaning of version if
there are multiple drops with the same version number?
Yukihiro Matsumoto
In message "Re: Purpose of Ruby 1.9?"
on Sat, 29 Dec 2007 12:22:19 +0900, "Rick DeNatale" <rick.d...@gmail.com> writes:
|> They will be bug fix versions. The spec will not be changed. If
|> changed, they were spec bugs.
|
|But will they all be version 1.9.0? What's the meaning of version if
|there are multiple drops with the same version number?
Note that the last version was 1.9.0-0. The forthcoming versions will
be versioned 1.9.0-1, 1.9.0-2, and such.
matz.