Rakudo build broken as of parrot RELEASE_2_10_1-633-ga3ca6c8

[Andy Dougherty]

On Tue, 30 Nov 2010, Andrew Whitworth wrote:

> Several functions were renamed by GCI students to help get TT #443.
> It's a deprecation item that has been eligible to be changed since
> 1.4.

> I'm not against keeping the old names around (as macros) to help ease
> the transition in theory. In practice, where do we draw the line?
> There has already been almost 2 years notice that the change would be
> coming. We've followed all the deprecation policy guidelines and
> waited plenty of time after eligibility to make these changes. How
> long do we need to keep exporting those names for the purpose of
> easing the transition? Forever?

No, not forever.

My complaint here is that there was no "transition" at all. The new 
function was not available to use before the old one was ripped out. If 
there had been a transition time when both were available, an HLL could 
start using the new function as soon as is convenient, and everything 
would just work.  Your question is asking how long that transition time 
should be.  I am merely saying it should definitely be longer than 0.

To say that it's been listed as "eligible" since 1.4 is completely 
irrelevant, because there's nothing anyone could actually do with that 
information to prevent this breakage.

I really appreciate your willingness to jump in and fix things up quickly.  
That's surely appreciated.  The background is that as various GC branches 
get merged, and various "tunings" are done, it expect it will be very nice 
to be able to test building and running rakudo under different parrot 
versions, and bisect to find places where problems arise.  If random 
steps along the way break the build for easily avoidable reasons, it makes 
such bisecting much harder.

Thanks again for trying to push things forward overall.

-- 
    Andy Dougherty		doughera at lafayette.edu