[#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: URABE Shyouhei <shyouhei@...>
Date: 2005-12-18 14:08:44 UTC
List: ruby-core #6939
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.

In short, it sounds like a pie in the sky to me.

Ryan Davis wrote:

> I'm concerned that 1.8.3's acceptance of non-backwards-compatible  
> changes to YAML is setting a bad precedence for ruby release  
> management. I don't think that point (read: bug-fix) releases should  
> accept and release anything that would break compatibility with  
> versions of the same major.minor value. Further, I don't think that  
> backwards incompatibility should be introduced on minor revs without  
> a minor rev in-between marking such a feature as deprecated.
>
> If this is the general consensus, I'd like to see the format change  
> in YAML be rolled back for 1.8.4 or for a soon-to-follow 1.8.5 to put  
> 1.8 back on track. If it is not the general consensus, I'd like to  
> put this on the table for discussion.



In This Thread