Version 1 by Wil Sinclair
on Mar 20, 2009 11:53.

compared with
Version 2 by Wil Sinclair
on Mar 20, 2009 12:06.

Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (9)

View Page History
Zend 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
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 *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.