Zend Framework releases will be identified in the form x.y.z, where:
1) Any increment of x denotes a major release
2) Any increment of y denotes a minor release
3) Any increment of z denotes a mini release
Each release may contain the following:
1) A major release may contain any changes, including bug fixes, backwards compatible features and functionality enhancements, and backwards incompatible releases.
2) A minor release may only contain backwards compatible changes, including bug fixes and backwards compatible features and functionality enhancements.
3) A mini release may only contain bug fixes. Note that no new features, functionality enhancements, or API changes are allowed whatsoever. The framework should look and behave the same across mini releases.
No attempt will be made to make Zend Framework releases forwards compatible.
New features are defined as changes that offer new or significantly enhanced API's. These features typically require proposals.
Functionality enhancements are defined as behavioral changes that do not affect- or minimally affect- one or more API's. Such functionality enhancements typically do not require a proposal
Exceptions to these policies will only be permitted for security fixes.
We try to build mini releases on a bi-weekly schedule. For example, the current release is 1.7.7. It was released on 3/6/2009. The next release will be called 1.7.8 and will be released on 3/23/2009.
We try to build minor releases once every quarter. That is, each release will be available 3-month after the last release as a rule of thumb. This convention is flexible; for larger releases we may require up to 6 months of development time.
We do not target any periodic schedule for major releases, as backwards compatibility will be broken only when the value-add for ZF users has become very high. Schedules for major releases can span well over a year.
These are only conventions; they will be updated or broken as necessary.