[#6864] ruby 1.8.4 rc breaks alias_method/rails in bad ways — "Ara.T.Howard" <ara.t.howard@...>

20 messages 2005/12/09
[#6870] Re: ruby 1.8.4 rc breaks alias_method/rails in bad ways — =?ISO-8859-15?Q?Florian_Gro=DF?= <florgro@...> 2005/12/12

Ara.T.Howard wrote:

[#6872] Re: ruby 1.8.4 rc breaks alias_method/rails in bad ways — ara.t.howard@... 2005/12/12

On Tue, 13 Dec 2005, [ISO-8859-15] Florian Growrote:

[#6873] Re: ruby 1.8.4 rc breaks alias_method/rails in bad ways — James Edward Gray II <james@...> 2005/12/12

On Dec 12, 2005, at 1:19 PM, ara.t.howard@noaa.gov wrote:

[#6874] Re: ruby 1.8.4 rc breaks alias_method/rails in bad ways — ara.t.howard@... 2005/12/12

On Tue, 13 Dec 2005, James Edward Gray II wrote:

[#6891] Time.utc! and Time.localtime! — Daniel Hobe <hobe@...>

Writing a script yesterday I found out, much to my surprise, that the

16 messages 2005/12/14

[#6918] change to yaml in 1.8.4 — ara.t.howard@...

14 messages 2005/12/16

[#6934] 1.8.x, YAML, and release management — Ryan Davis <ryand-ruby@...>

I'm concerned that 1.8.3's acceptance of non-backwards-compatible

28 messages 2005/12/18

[#6996] Problems building 1.8.4 with VS8 C++ Express Edition (cl 14.00) — Austin Ziegler <halostatue@...>

Visual Studio C++ 2005 Express Edition (VS 8.0)

20 messages 2005/12/27

Re: 1.8.x, YAML, and release management

From: Ryan Davis <ryand-ruby@...>
Date: 2005-12-19 20:58:15 UTC
List: ruby-core #6957
On Dec 18, 2005, at 6:08 AM, URABE Shyouhei wrote:

> Acceptable or not matz releases 1.8.4 this Saturday.  It's hard to  
> believe he reschedules.  And the 1.8 branch has already been frozen  
> for 1.8.4 release.  It's too late.
>
> As I wrote in [ruby-core:6938], there cannot be any 1.10.x  
> releases.  This means the version number we can use are very  
> limited. So I strongly disagree with wasting our precious 1.8.5 to  
> release in a second after 1.8.4.

I understand your disagreement, but at the same time, I'm afraid this  
is the price to pay to fix backwards compatibility problems. I'm no  
rails fanboy, but you simply cannot ignore ruby's biggest proponent  
stating this on the download page:

	We recommend Ruby 1.8.2 for use with Rails despite the presence of  
1.8.3.
	The latter has had a number of issues that would encourage people to  
stay
	on the former and await Ruby 1.8.4.

The same is true for rubygems, the biggest distribution system for  
ruby. The simple fact is this: ruby is broken and it shouldn't be. It  
needs to be fixed. I don't think fixing major backwards compatibility  
issues to be a "waste" of a version number.

Hopefully, as _why stated, we can still slip this into 1.8.4.


In This Thread