On Wed, Dec 01, 2010 at 10:45:11AM -0500, Andrew Whitworth wrote: > On Wed, Dec 1, 2010 at 10:18 AM, Peter Lobsinger <[email protected]> wrote: > > I get the sense there's an expectation that rakudo should always build > > and run cleanly against parrot head. I don't recall this ever being > > explicitly supported, and I think that it is not feasible in the > > general case (I do agree that in this specific case it would have been > > a possibility). > > What we really need to know are the exact parameters that Rakudo is > willing to put up with during these kinds of disruptions, with the > obvious tradeoff being that more tolerance towards disruptions brings > more features and better performance, and brings all these things > faster.
First, let me add my strong +1 to the notion that a deprecated feature should not be removed before its alternative has appeared in at least one release (ideally at least one "supported" release). As to what Rakudo is "willing to put up with"... IIUC, Parrot's official policy continues to be that HLL developers should target "supported releases" only. Rakudo explicitly and knowingly ignores that policy, because advancing Rakudo at a reasonable pace often means we need access to the new Parrot features long before they'll be available in a supported release. Indeed, we often need them before they're available in a monthly release, which is why Rakudo head often targets Parrot head and not simply monthly releases. Because Rakudo doesn't follow Parrot's official policy, Rakudo is willing to put up with a lot of disruption in Parrot head. In other words, Rakudo definitely requires "more features and better performance" from Parrot over "stability", which is why our development targets Parrot head and not Parrot releases, and we try to gracefully accept the inevitable disruptions that can come from that choice. On the flip side, Rakudo often ends up serving as Parrot's canary in the coal mine, by exposing deprecation and other issues in Parrot head before they get "solidified" into a Parrot release where they *would* impact users that are following the Parrot policy. In other words, if Rakudo developers weren't targeting Parrot head, would these sorts of issues be detected before a Parrot release? So, Rakudo doesn't have an expectation that we can always build and run cleanly against Parrot head; however, we'd like to have any problems detected and resolved quickly, and definitely before the "non-building Parrot head" becomes "a non-building Parrot release". If a problem exists into a Parrot release, then Parrot and all of the HLL users (not just Rakudo) have to scramble a bit to deal with the fallout. That's the primary reason many of us test and build Rakudo against Parrot head, and why we report problems when they occur. It's not that we expect Rakudo to always build and run cleanly against Parrot head -- it's that when Rakudo doesn't build and run cleanly against Parrot head, it likely points to a problem that could affect many Parrot users that ought to be fixed prior to the next Parrot release. Pm _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
