Support Policy Update Proposal

Andrew Whitworth wknight8111 at gmail.com
Thu Dec 3 13:15:23 UTC 2009


On Wed, Dec 2, 2009 at 10:46 PM, Will Coleda <will at coleda.com> wrote:
> One big ticket, non-code item that is on the table right now is
> changing our support policy from a six-month stable cycle to a three
> month cycle: making 2.0, 2.3, 2.6 and 2.9 stable releases for the
> upcoming year; two of those will probably end up getting targeted for
> linux releases, and the more frequently release schedule as we
> continue to improve at a rapid pace should give some relief to
> language authors.

Based on some ideas that were kicking around IRC yesterday, I have
prepared a rough draft of a new support policy that I would like to
open up for broader consideration. This draft changes the policy from
an "opt-out" to an "opt-in" policy. Instead of all public-facing
interfaces being supported and non-supported items having to be
explicitly removed, I would like to move to a system where nothing is
supported by default except for items that we explicitly approve and
put on a list.

This serves two purposes:

1) It acknowledges that many parts of Parrot are still under
development and it doesn't make sense to guarantee the form or
function of a feature that is essentially a prototype
2) It allows us to specifically list the things we do and do not
support, instead of having a general description of the types of
things we cover with some very unclear edge cases ("does the support
policy even cover X?").
3) It provides a mechanism where users and HLL devs can tell us what
kinds of features they are relying on so we in turn can make effort to
revise, refactor, stabilize, and support that interface.
4) It allows us more flexibility in refactoring and improving,
sometimes radically, those parts of the system that are immature,
buggy, or suboptimal, without having to wait several months to make
necessary fixes.
5) It gives us motivation to take explicit inventory of our public-facing API.
6) Gives us an explicit list of externally-visible items that require
improved user documentation
7) It allows us to better prioritize development effort by identifying
holes in the API and compare those with the needs of our HLL and
library devs.

On a regular basis we can take a look at ongoing development and
explicitly mark off items that have reached a stable and acceptable
level, and items cannot come back off that list without following a
normal deprecation cycle. This is an early draft, but I think many of
the ideas in here would be very beneficial to both Parrot development
and HLL development, judging from the discussion yesterday and several
complaints I have heard over the past few months.

--Andrew Whitworth
-------------- next part --------------
A non-text attachment was scrubbed...
Name: support_policy_DRAFT.pod
Type: application/octet-stream
Size: 8866 bytes
Desc: not available
URL: <http://lists.parrot.org/pipermail/parrot-dev/attachments/20091203/1e8ce3bb/attachment.obj>


More information about the parrot-dev mailing list