The Perl Toolchain Summit needs more sponsors. If your company depends on Perl, please support this very important event.

NAME

docs/project/support_policy.pod - Parrot Release and Support Policy

ABSTRACT

This document describes Parrot's release schedule and support policy.

Parrot Release and Support Policy

Parrot's support policy -- for bug reporting, patches, and releases -- relies strongly on its release schedule.

Release Schedule

Parrot currently follows a monthly cycle; we produce a new stable release of Parrot on the third Tuesday of each month. This will continue into the forseeable future.

However, we will concentrate our efforts to produce two milestone releases each year, one in January and one on July. The January release will be an x.0 release and the July release will be an x.5 release. Don't read too much into these numbers; they represent the points at which we believe we will have delivered complete sets of major features.

Deprecations

We will regularly deprecate features and remove them. All deprecations must have an announcement in at least one stable release before removal. In practice, the milestone releases mark the points at which we will begin removing deprecated features. That is, a feature deprecated in Parrot 2.1 (February 2010 release) will likely be removed for Parrot 2.6 (August 2010 release). Likewise, a feature deprecated in Parrot 2.5 (June 2010) may be removed as early as Parrot 2.6 (August 2010) -- but it is likely we will stagger the removal to give several months of notice between deprecation and removal.

Supported Older Versions

We support a version of Parrot by accepting patches and bug reports for that version and by answering questions and helping to explain the code to users and developers. We will do our best to fix all reported bugs, though we reserve the right to triage bugs based on their severity, the difficulty of reproducing them, their platform characteristics, and other criteria. As we are primarily volunteers, we offer no warranty nor guarantee of support other than our pride in producing great software as a community.

We support only the most recent milestone family. That is, after the 1.0 release, we will support releases numbered 1.x. After 1.5, we reserve the right to drop support for previous 1.x releases. We offer no guarantees of support for older releases; volunteers may provide support for these versions, but that is their own decision and not an official policy.

We recommend that you update to the most recent monthly stable release in a milestone family. We may release patches for previous releases, but in general we will not release updates for previous releases.

We heartily recommend that you take the initiative to help us help you, by providing useful information about potential bugs and by answer diagnostic questions -- perhaps even trying patches or specific revisions.

We reserve the right to release updates to address severe security problems, per our determination of applicability and severity.

If you have received an older release packaged by an operating system vendor or third party, please contact your vendor for updated support.

Forward Compatibility

We reserve the right to change the format of bytecode in the future, in accordance with our deprecation guidelines. We plan to develop tools to migrate from bytecode formats, but we recommend that you rely on the Parrot Compiler Toolkit (PCT) to generate code for distribution.

Platform Support

We commit to running (passing all tests) on our supported platforms.

We support recent versions of the three major operating system families: GNU/Linux, Mac OS X, and Microsoft Windows. Any version less than two years old counts as "recent".

We support the most recent version of the dominant compiler which conforms to the C89 standard on each supported platform.

We may not support all additional features on every platform (JIT, native binaries, alternate runcores), but the default configuration and runstate of Parrot will work on all supported platforms.

We do not preclude supporting other platforms and compilers, but we cannot commit to supporting such platforms without at least one champion for each platform. We reserve the right not to support a platform if doing so would create an undesirable support burden for the other major platforms.

Deprecation Candidates

If it's publicly available, a backwards-incompatible changes requires deprecation:

  • bytecode changes (ops or core PMC removals, renames)

  • PARROT_API function changes