On one hand we have been calling particular releases "supported" and "developer". This distinction does still show up in our release manager guide, is used for download links on the website and the FTP server, etc. On the other hand, we haven't really been inundated for requests for "support" to the point that we need to be actively limiting the number of releases that we call "supported". All releases are pretty well tested, and it's up to the discretion of the release manager whether a supported release is treated any differently or more conservatively than other releases. The big differences being a slightly longer code freeze on master, maybe a little bit more testing, etc. Because all releases come out of the same master branch, and because the procedure for cutting them is all the same, there isn't going to be any substantive difference between different releases.
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. Losing that part of the policy has not, I don't think, caused any real problems. We've replaced a brain-dead time-based policy with a more intuitive and responsive mandate that Rakudo head needs to keep working regardless of changes in parrot. 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. Some changes made will, by necessity, be backwards incompatible. We should align those kinds of changes with boundaries that work well with Rakudo. If that means Parrot's supported releases, we can definitely do that. --Andrew Whitworth On Thu, Jul 5, 2012 at 11:55 PM, Patrick R. Michaud <[email protected]> wrote: > I'm looking at updating the release guides for Rakudo, Rakudo Star, > and NQP, and have a question about Parrot releases: > > Is Parrot still using the "supported" versus "developer" release > policy in any real way? > > Rakudo's policy has always been that Rakudo releases target a > Parrot release (i.e., we never release a Rakudo that relies upon > an unreleased version of Parrot). But we're now starting to hi > t the situation where any given Rakudo release could potentially > run on multiple Parrot releases. > > So, if a Rakudo release manager has a choice between multiple > Parrot releases, should the manager always choose a "supported" > Parrot release, the earliest possible Parrot release, or the > latest Parrot release? > > As a more concrete example, the 2012.06 release of Rakudo could > build and run successfully on either Parrot 4.4.0 or 4.5.0. > Our traditional release policy has been to always bump our > minimum release to the latest released Parrot (either supported > or developer); I'm wondering if we should relax this a bit, > and what our guidelines should be for selecting a minimum Parrot > release for Rakudo and NQP. > > Suggestions and opinions welcomed. > > Pm > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
