pysoy roadmap

Since it's been requested, here's the timeline for PySoy 1.0. Note that hit some of these dates far earlier than projected.

Friday, April 13th: API overhaul (mostly) complete, pushed to SVN and "unfrozen" for continued development

As the new maintainer, in an effort to bring order to chaos, I've frozen development while I restructure the API (and thus the code). On April 13th, if not before, a major SVN commit will be made with these changes. Any bugs I find but cannot fix along the way are being entered into the ticket system for dealing with later, my focus is overall structure and getting coreloop working well under the structure we previously conceived.

Between 4/13 and 5/28, our Summer of Code students will be getting up to speed on what we're doing and our development practices.

Monday, May 28th: Our Summer of Code students begin work.

Since they are working full-time, the three of them together represent a majority of the work being done over the Summer. This is not to say the rest of the development team isn't working as well, but most of what we'll be doing is re-implementing the code we've already done into the new API and debugging/optimizing it. By contrast, the students will be adding new code we have not worked on before so their jobs are significantly more time consuming.

Friday, June 29th: First "beta" release, SVN read access open to public

By the end of June we'll release the codebase as we have it for public viewing. There will be no guarantee that the API will remain the same between this and 1.0 but changes, if any, will be minor. The primary reason for doing this is to get sample games ready before 1.0 release and get input from the larger community on ways it could be further polished.

Summer of Code work will not even be to midterms at this point, but some preliminary student work should be available by this point. There may also be additional "beta" releases between this and the final release.

Friday, August 18th: Release Candidate 1

At least one release candidate will be made prior to 1.0, each with a 48 hour window to find any remaining bugs or issues (ie, a missing file or #ifdef for a platform). Any change represents a new RC with new 48 hour window.

Friday, August 24th: 1.0 Release

We want to hit the "end of summer" deadline and have 1.0 released with the SoC students work included. This leaves enough time for potentially three or four release candidates prior to final release.

1.0 represents a stable API which can be safely developed for.

Thereafter: 1.1 and beyond

Further development remains backwards compatible to code designed for 1.0 while adding new features, optimizing it's speed, or fixing a few fringe-case bugs we missed.