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.
on 26.12.2007 21:51
on 26.12.2007 22:18
You are asking very usefull questions! Well... we need wait to someone answer ;) Regards, Luiz Vitor. On Dec 26, 2007 6:50 PM, Radosław Bułat <radek.bulat@gmail.com> wrote: > 2.0 stable etc) I've read dissenting opinions of it. > > -- Regards, Luiz Vitor Martinez Cardoso [Grabber]. (11) 8187-8662 rubz.org - engineer student at maua.br
on 26.12.2007 22:45
> 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.
on 26.12.2007 23:29
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
on 26.12.2007 23:40
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.
on 26.12.2007 23:53
On Dec 26, 2007 5:39 PM, Windham, Kristopher R. <kriswindham@gmail.com> 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/
on 27.12.2007 00:12
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
on 27.12.2007 00:16
Hi,
In message "Re: Purpose of Ruby 1.9?"
on Thu, 27 Dec 2007 07:29:41 +0900, Wolfgang N1dasi-onner
<ed.odanow@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.
on 27.12.2007 00:24
On Dec 26, 2007 6:11 PM, Dave Thomas <dave@pragprog.com> 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/
on 27.12.2007 01:34
Matz and others - thanks for answers. It's great news for me. I'm starting exploring new Ruby features. I love this language! :)
on 27.12.2007 08:53
On Dec 27, 2007 7:11 AM, Dave Thomas <dave@pragprog.com> 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
on 27.12.2007 09:46
On Dec 27, 2007, at 8:53 AM, botp wrote: > On Dec 27, 2007 7:11 AM, Dave Thomas <dave@pragprog.com> 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
on 27.12.2007 10:29
botp wrote: > 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. :)
on 27.12.2007 10:59
On 27 Dec 2007, at 08:45, Xavier Noria 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
on 27.12.2007 16:05
On Dec 27, 2007 4:28 AM, M. Edward (Ed) Borasky <znmeb@cesmail.net> 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 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. -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/
on 27.12.2007 16:17
I don't believe that can happen.. Ruby programmers like to be on the cutting edge, it seems..
on 27.12.2007 17:30
On Dec 27, 12:04 pm, Rick DeNatale <rick.denat...@gmail.com> 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 Lavena
on 27.12.2007 19:10
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
on 27.12.2007 21:41
Rick DeNatale wrote: > On Dec 27, 2007 4:28 AM, M. Edward (Ed) Borasky <znmeb@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.
on 28.12.2007 00:00
> 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! :-)
on 28.12.2007 05:43
Hi On Dec 27, 2007 5:50 AM, Rados³aw Bu³at <radek.bulat@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.
on 28.12.2007 15:57
On Dec 27, 2007 11:43 PM, Leonard Chin <l.g.chin@gmail.com> wrote: > - 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. -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/
on 28.12.2007 22:15
Leonard Chin wrote: > * 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
on 29.12.2007 00:47
Hi,
In message "Re: Purpose of Ruby 1.9?"
on Fri, 28 Dec 2007 23:57:10 +0900, "Rick DeNatale"
<rick.denatale@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.
on 29.12.2007 01:12
> 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. 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
on 29.12.2007 04:22
On Dec 28, 2007 6:46 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote: > |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. 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? -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/
on 29.12.2007 06:41
Hi,
In message "Re: Purpose of Ruby 1.9?"
on Sat, 29 Dec 2007 12:22:19 +0900, "Rick DeNatale"
<rick.denatale@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.