compared with
Version 5 by Darby Felton
on Jul 18, 2007 11:19.

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

Changes (13)

View Page History
h1. Document Overview

The goal of this document is to clearly articulate the development lifecycle methodology for Zend Framework. There are many challenges in managing such a project, mainly due to the large number of contributors, the increasing amount of translated documentation, and the need to release both stable mini releases while working on more significant releases in parallel.

The goals in writing this This methodology are to find should strike the right balance between a high-quality process and to make making it reasonably easy to become a contributor. The suggested practices in this document aim to meet these goals, but they will only succeed with the help of peer review and support.

Over time we will continue to evolve and update these practices based on real-world application.
h2. Core

The trunk of the framework repository, from which minor and major release candidate branches are generated, is known as the framework core.

Before code is permitted to enter the framework core, passing unit tests and documentation are required.
h2. Incubator

The incubator directory is where new development matures to a state acceptable for the framework core, from which minor and major release candidate branches are produced. It should be used to develop first-time components after their respective proposals have been accepted. It is also used to develop new component adapters (e.g., for Zend_Auth, Zend_Cache, Zend_Db) and to implement large units of work such as major architectural changes or experimental improvements. Once such new developments reach the project's baseline for quality (code, unit tests & documentation) they will be promoted and maintained in the trunk directory.

If multiple parallel development efforts should occur for a given component, then additional branches of the main development line may be provided for accommodating the work. In any case, software configuration management solutions, such as Subversion, are no substitution for effective communication among developers.
h3. Backward Compatibility

Backward compatibility should strictly be adhered to in mini releases unless a high-impact critical bug such as a security bug demands otherwise. In some many cases adding minor feature enhancements is acceptable if they are self-contained and the release master decides these changes are at low risk of impacting existing functionality.

h3. Release Cycle

Mini releases will not be date driven. They will be driven at the discretion of the release master when he believes enough fixes have accumulated to warrant a release. We believe such releases will be done initially every 4-8 weeks. For high-impact critical bugs the release master may decide to release sooner. The mini release branch should always be stable and in a releasable state, to facilitate the timely generation of an emergency release should the need arise.

h2. Minor Release
h3. Release Cycle

Major releases will usually be driven by a combination of features and date. It They would include the minimum amount of features in order for the major release to be considered appropriate but then may very well be driven by a release train in order to bring the release to completion. We expect major releases to come out approx. every 18 months.


It is recommended that developers checkout a working copy of each of the trunk (core) and any active release branches. The above command illustrates how to checkout the framework trunk, and the following command checks out the release-1.0 branch into a sibling directory:

$ svn checkout ZendFramework-release-1.0

h2. Switching a Working Copy between Branches

Though developers will likely find it most convenient to have separate working copies of the trunk (core) and a release branch, it is possible to switch a single working copy between branches. You can switch all or a portion of your working copy between two branches by using the {{[svn switch|]}} command, as in the following example, where a working copy of the trunk is switched to a hypothetical purpose branch containing experimental Zend_View changes:

h2. Merging Changes

Merging changes from one branch to another is made quite simple in Subversion, since it is merely a copying of differences between revisions. Since, at the time of this writing, the framework Subversion repository does not natively support merge tracking, it is very important to *note the applicable revision range for all merge operations in the commit message*, as in the following example:

h2. JIRA Workflow

When a committer fixes a bug, it should be marked as fixed for all versions of the branches to which the fixes have been applied. For example, if a fix is committed to the trunk, then it will be included with the next minor release. or major release, whichever occurs first. If the same fix is then merged to one or more release branches, then the JIRA issue should also be marked as fixed for the next mini releases associated with those branches.

As an example, assume that you have just committed to the trunk a code fix for a small bug in a framework component, along with unit tests that confirm the desired resulting behaviors. Zend Framework 1.0.0 has just been released, and the next planned release is a 1.0.1 mini release. The next minor release is planned to be 1.1.0. The associated JIRA issue that tracks the bug should be marked as fixed for 1.1.0. Once the changes are reviewed, you should merge the changes to the 1.0 release branch, so that they may also be included in the 1.0.1 release. Once you have committed the merge, mark the JIRA issue as fixed for not only 1.1.0 but also 1.0.1.

h1. Repository Structure Explained