Puppet: System Administration Automated

Support

Puppet Development Road Map

This document describes the planned road map for Puppet's development. Even having a roadmap is relatively new to Puppet, so we have not yet had time to establish how the roadmap will change over time. This document will be maintained and be as correct as possible at all times, but ping Luke or James if it seems out of date.

The Purpose of This Document

Like most roadmaps, this document serves both the development and user community. It gives developers an idea of when they're expected to have a given set of work done, and it gives users an idea of when to expect a given set of functionality and when to expect existing functionality to change or go away.

Planned Releases

  • 0.24.7: We’re going to get this release out as soon as possible (most likely around the middle of November), with any critical fixes resulting from the 0.24.6 release. This will be the last stable release in the 0.24.x line.
  • 0.25: This release will be the first release from the master branch, and is planned for the end of the year. Its primary changes will be all of the plumbing to support REST, plus converting, at a minimum, file serving and catalog retrieval to using REST.
  • 0.26: This release will convert any remaining XMLRPC network APIs to REST, and will be the last release before 1.0. It should be out in the second quarter of 2009. It will also allow multiple primary keys for resources.
  • 1.0: This release stabilizes the network API: According to the plan, projects developed against its API should work going forward.

Beyond those short-term releases, we've got a basic plan for forthcoming releases. At this point, the only bullet points in the later releases are related to refactoring, but we'll be adding features as we come up with plans for them.

2.0

  • Refactor of the transactional system. The primary goal here is to remove all of the ugly code around the transactions and RAL.

3.0

  • Refactor the RAL. After this release, any custom types and providers will work going forward. Any custom types and providers written before this release are considered to be against an unstable API, and while every attempt at backward compatibility will be made, it cannot be guaranteed.