> So, in short, we don't really treat them substantially different. We > did reject the deprecations part of the support policy, and using > supported releases as a deprecation boundary was really their biggest > purpose for a while. Without that, there isn't a "real" substantive > difference. [...] > > Just because we don't treat them any differently doesn't mean that we > couldn't or even that we shouldn't. If Rakudo would like a particular > behavior with respect to supported releases, we can definitely talk > about implementing that.
Rakudo doesn't have any specific needs in this area; what we have now is working fine. I just wanted to know about Parrot's directions in this area. I also suspect that distribution packagers (e.g. Debian) will want to have some guideline for identifying Parrot's "stable" releases that they should choose when preparing packages for inclusion in OS repositories. As it is now, I think the Debian packagers always choose Parrot's "supported" releases, and then pick a corresponding Rakudo from that. Based on your message, I'm guessing that Rakudo should always list the "oldest workable version" of Parrot as its PARROT_REVISION. This means that Rakudo 2012.07 may end up listing Parrot 4.4.0 as its "minimum version", although we'll certainly test it against Parrot 4.6.0 when it comes out in a couple of weeks. Of course, if anything happens whereby we find that Rakudo/NQP absolutely require a Parrot newer than 4.4.0, we'll bump the next PARROT_REVISION to 4.6.0 automatically. Thanks! Pm _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
