Parrot support policy still active?

[Andrew Whitworth]

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 <pmichaud at pobox.com> 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