1.9 Backport?

[Trans]

Reading:
http://www.ruby-lang.org/en/news/2006/10/26/rubyconf-2006-recap/

If Ruby 1.9+ won't be released for over a year, can we backport a few
features? Most noteabley #instance_exec and the ability of a block to
take a &block argument --the lack of these exact a heavy toll on good
clean metacode.

Also, is it true RCRchive is to be no more?

Thanks,
T.

 

[Austin Ziegler]

Reading:
http://www.ruby-lang.org/en/news/2006/10/26/rubyconf-2006-recap/
If Ruby 1.9+ won't be released for over a year, can we backport a few
features? Most noteabley #instance_exec and the ability of a block to
take a &block argument --the lack of these exact a heavy toll on good
clean metacode.

Probably not. Ruby 1.8 is supposed to be *stable*, and I doubt that
there'll be a shim like there was for Ruby 1.6 to 1.8, either.

Also, is it true RCRchive is to be no more?

No. Take a look at my blog; RCRchive is going to change focus into
probably being a starting point for discussion, but *how* such entries
are processed will probably change from the current software to
something else that allows for mailing-list discussions.

-austin

 

[Bil Kleb]

Reading:
http://www.ruby-lang.org/en/news/2006/10/26/rubyconf-2006-recap/

Also, is it true RCRchive is to be no more?

No.

RCRchive is to be remade. Most RCRs will be tossed
because new RCRs are required to explain the *WHY*
behind the proposed change and come replete with tests
and sample implementations. (Most current RCRs don't
satisfy these criteria.)

See Matz's keynote,

http://www.travelistic.com/video/show/985

beginning with bikeshed at 7:30.

Later,

 

[James Edward Gray II]

No.

RCRchive is to be remade.

Sorry, that was sloppy explaining on my part. I've tried to clean it
up.

James Edward Gray II

 

[dblack]

Hi --

No.

In fact, I'm hard at work on the new RCRchive. Stay tuned. It's
going to operate somewhat differently, and will be focused on 1.9/2.0
changes.

RCRchive is to be remade. Most RCRs will be tossed
because new RCRs are required to explain the *WHY*
behind the proposed change and come replete with tests
and sample implementations. (Most current RCRs don't
satisfy these criteria.)

Mind you, they're supposed to It's always been a requirement that
proposals include Abstract, Problem, Analysis, and Implementation --
lots of "why", etc. Most RCRs are done conscientiously and
diligently, but some are not very complete. Hopefully the new
logistics of the process will encourage more consistent compliance.


David

--
David A. Black | (e-mail address removed)
Author of "Ruby for Rails" [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] http://www.manning.com/black | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org

 

[Trans]

Probably not. Ruby 1.8 is supposed to be *stable*, and I doubt that
there'll be a shim like there was for Ruby 1.6 to 1.8, either.

Right. I realize. I was just hoping that a few significant features
that are pure "superset" could make it back.

T.

 

[Austin Ziegler]

Right. I realize. I was just hoping that a few significant features
that are pure "superset" could make it back.

I sympathize, but I read something about the Denver Summit (posted on
RedHanded by Daigo) indicating that absolutely no new features will be
added to Ruby 1.8. Just bug fixes.

-austin

 

[Michael Trier]

I sympathize, but I read something about the Denver Summit (posted on

RedHanded by Daigo) indicating that absolutely no new features will be
added to Ruby 1.8. Just bug fixes.

In the roundtable there was a specific question about backporting some
functionality. I don't recall the functionality that was being
discussed, but I clearly remember Matz indicating that he would be
willing to backport functionality if it had no impact on the current
code. The specific item being discussed wouldn't have, and he said he
would be open to looking at it.

Michael

 

[Keith Fahlgren]

Hi --



In fact, I'm hard at work on the new RCRchive. Stay tuned. It's
going to operate somewhat differently, and will be focused on 1.9/2.0
changes.

Cool. Let's just make sure that the old ones don't get "tossed', as
I'm sure there'll be some historical value in them.


Thanks,
Keith