|
Key
This line was removed.
This word was removed. This word was added.
This line was added.
|
Changes (9)
View Page HistoryZend Framework releases will be identified in the form x.y.z, where:
h2. Policies
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
2) Any increment of y denotes a *minor* release
3) Any increment of z denotes a *mini* release
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*
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 *backwards incompatible releases*.
2) A *minor* release* may contain only backwards compatible changes, including *bug fixes* and *backwards compatible features*.
3) A *mini* release* may contain only *bug fixes*. *Note that no new features or API changes are allowed whatsoever.*
No attempt will be made to make Zend Framework releases forwards compatible.
h2. Conventions
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.