Submitted by allison on Wed, 12/17/2008 - 03:58

The Parrot Developer Summit last month was incredibly productive. One of the biggest results was a roadmap for the next several years of releases, starting with the 1.0 production release in March 2009. Many of us on the project have been treating 1.0 as the perfect release where all features we could ever hope for are completed. But the simple fact is, there will always be interesting new features to add to the project, and that's a good thing. The paradigm shift for the new release plan is to start treating 1.0 more like we already treat our regular monthly releases.

So, here's the plan: We'll continue with our monthly development releases, which set a healthy pattern in the development cycle. Starting with the 1.0 release next March, and every July and January after that, two releases a year will be stable releases. The stable releases will be numbered X.0 and X.5 (1.0, 1.5, 2.0, 2.5, etc), to set them apart from the development releases, where X.0 is the January release, and X.5 is the July half-year release. The stable releases are the ones that will be packaged for distributions like Ubuntu, Debian, Red Hat, and SuSE, installation systems like Fink or MacPorts, and binary builds for various OS's. Monthly releases will not be packaged, though critical bug and security fixes will be maintained in updated packages (1.0.1, 1.0.2, etc). Most language developers will work from the stable releases so they don't need to track the rapid pace of development in the main source repository or monthly development releases.

The stable releases will also set the pace of the deprecation cycle for development. Parrot's current deprecation cycle is one release (one month), so any feature that's marked as deprecated in one release is fair game to remove in the next release. This policy has been healthy for cleaning out old cruft, but it's also hard on the language developers. Starting with 1.0, the deprecation cycle will follow the stable releases instead of the monthly development releases, so any feature that's marked as deprecated when, for example, the 1.5 release is shipped, can be removed from the 2.0 release, but will continue to be supported for the 6 months until the 2.0 release.

Each stable release has a particular focus that defines what features are critical for that release. The focus for the 1.0 release is "a stable API for language developers". Parrot isn't a language, it's a virtual machine and set of powerful tools for language implementors. So, the first audience we have to address is those implementors, and 1.0 will provide them with a complete set of core subsystems and feature-rich compiler tools, with the guarantee that the interface will only change on the standard 6 month deprecation cycle.

1.0 also marks the point where we're willing to support Parrot in production environments. This doesn't mean we expect a thousand companies to run out and ship Parrot-based products the next month. A three-year adoption cycle is a fairly standard pattern in the industry, so that's what we're planning for. The first year is the early adopters, the second year is initial production use, and the third year is more substantial production use.

The next few years of stable releases are planned around the ideas of the adoption cycle and deprecation cycle, and to make sure we always have a few interesting new features to look forward to in each release. The focus of the 1.5 release is "integration, interoperation, and embedding" meeting the needs of the second largest group of early adopters. The focus of 2.0 is "production users", that is the little extra bit of spit and polish to make Parrot and its major language implementations appealing to the second-year production adopters. 2.5 is about "portability", supporting more platforms, more languages, and the needs of a larger and more diverse user-base.

3.0 is about "independence", removing the last traces of Perl and Python from the build and testing frameworks, and running everything on system-available build tools, on Parrot, or on a bootstrapped mini-parrot. 3.5 we call "green fields", for ponies, unicorns, marshmallows, and a theme song by Brian Eno. No, seriously, at that point our current vision for the core of Parrot is fully implemented, and we anticipate substantial production use. Gradually over the three-year adoption cycle, the focus will shift from developing Parrot itself to developing interesting things with Parrot: applications, games, desktop extensions, teaching tools, research projects, domain-specific or experimental languages, installer frameworks for Linux distributions, lightweight dynamic language support on embedded devices, and a host of other uses for a next-generation open source virtual machine. I can't wait to see where human imagination takes us.