Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History

To download the developer version now, just type: svn checkout

Zend Framework Subversion Standards

What is Subversion?

"SVN (Subversion) is a tool used by many software developers to manage changes within their source code tree. SVN provides the means to store not only the current version of a piece of source code, but a record of all changes (and who made those changes) that have occurred to that source code. Use of SVN is particularly common on projects with multiple developers, since SVN ensures changes made by one developer are not accidentally removed when another developer posts their changes to the source tree."

For more information, please visit the official Subversion site.

The Zend Framework Subversion Repository

The Zend Framework is an open source project, and the complete source code can be downloaded anonymously by direct checkout from its Subversion repository. For information on how to receive automatic notification of changes and updates to the Zend Framework and documentation, please see [Zend Framework RSS Feeds and Notifications].

Also see these examples showing how to make patches.

Anonymous Checkout

The most up-to-date working copy of the Zend Framework is the trunk. This includes all the newest features and bugfixes and incubator components. However, the latest versions of each file often have far less testing, and may or may not have fewer bugs than the versions found in the most recently released, stable version of the Zend Framework in the Download area.

SVN Checkout

Please report new bugs, submit patches, or comment on posted issues using the Issue Tracker on the Developer's Wiki.

Anonymous Checkout using MS Windows

  1. Install TortoiseSVN and restart your computer
  2. Create a new folder called "ZendFramework-trunk"
  3. Right click on the new folder, choose "SVN Checkout", and enter this URL:
  4. The officially released Zend Framework core components will be in the subfolder "library" inside of the "ZendFramework-trunk" folder.
  5. Released incubator components (see next section) will be in the subfolder "incubator" inside of the "ZendFramework-trunk" folder.
  6. Before reporting bugs, first update your downloaded copy of the framework by right-clicking on the "ZendFramework-trunk" folder and selecting "SVN Update".

Using the Zend Framework Incubator Components

Follow the procedure above for "Anonymous Checkout". After proposals for new components or major rewrites of existing components have been accepted, the new components are first placed into the "incubator":

When incubator components are considered sufficiently mature and stable enough, then they are moved into the normal location for Zend Framework components. Incubator components are not bundled with the Zend Framework download, but are included with the Subversion download/checkout process.

Those wishing to use incubator components, may use them by modifying PHP's include path:

See also the Zend Framework Proposal Process.

Prior Release Versions

All versions of the Zend Framework that are released to the public are tagged and also available for download from the repository. Checkout or export and check the tags directory for previous releases.

Using Subversion from behind a Proxy / Firewall

Squid: If svn does not work on your lan, and you have a Squid Proxy (ask your IT staff), then try adding these 3 lines of code to the Squid Proxy's squid.conf file:

Subversion Write / Commit Access

Frequently, suggesting and making changes works best when attaching a patch to an issue in our issue tracker. The community will have an opportunity to review your patch, comment on your notes in the issue ticket, and make suggestions. Then, you can review these comments and possibly make improvements to the patch, before it is committed.

Access SVN is granted to component area leads and higher volume contributors. If you need access to SVN you may request it on the mailing list or through a component lead that you have worked with previously.

A few rules should be kept in mind when using SVN:

  • All commits should contain commit comments.
  • If a commit is resolving an issue from the issue tracker, the issue KEY should be indicated in the commit comment (i.e. "This resolves ZF-2"). This will cause it to be auto-linked from Fisheye to the issue, and also the reverse link from the issue back to Fisheye. The issue key can be seen when viewing any issue in the upper left corner of the screen.
  • All commits that would affect release notes should have an associated issue in the tracker. There are issue types for most situations, and if it is just a significant change that does not fit into another category, use the issue type "Patch."
  • It is no longer neccessary to update NEWS.TXT as the issue tracker will be used to generate release notes.
  • When resolving an issue, feel free to edit the issue's title to be clearer based on anything you learned while fixing it. This will aid the readability of the release notes.
    Create new dirs for new proposal

How often should code be committed to the Subversion repository?

Released Components (including released incubator components)

Avoid breaking existing functionality.

Commit your changes as often as code is completed and tested successfully. No code should enter the repository that is not tested, but you also may not want to hold off on committing large chunks of work that are incomplete, and in this case, interstitial commits should be acceptable, so long as they do not break existing functionality.

Unreleased Incubator Components

Prior to the first public release of an incubator component, incubator contributors should commit early and often, regardless of unit tests and documentation completion. Indeed, documentation will require reworking as often as the API changes, and it is unnecessary to have to do this reworking for incubator components not yet selected for release in the core framework. Although most consider testing while developing best practice, it is more important that code enter the repository on a daily basis for enabling review and continuous work by other framework contributors. That is, incubator contributors should commit their outstanding work on a daily basis, whether it is "complete" or not, until the component is selected for inclusion with a public release of the Zend Framework (including a publicly released incubator component). After the time when a component is selected for release, the more strict policy of committing only unit-tested code would apply, and the API should stabilize enough for writing documentation to be included with the release.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.