View Source

<h3>Introduction</h3>

<p>In the IRC meeting on <ac:link><ri:page ri:content-title="2012-03-07 Meeting Log" /><ac:link-body>7th March</ac:link-body></ac:link> it was broadly agreed that most of the components that currently live in the ZF1 Zend_Service namespace (generally components that interface with 3rd party APIs) should be taken out of the ZF2 Zend\Service namespace, and should be moved to their own components. This means that the service components will not be constrained by the release cycles of the Framework proper, useful because service classes often need to be changed quickly to reflect changes in their parent APIs. Service components will be released on their own cycle, independent of the Framework proper and each other. It also means that service modules will not ship by default with the Framework, meaning end-users will have to install them manually from whichever packager source is used. It also simplifies the process of using our service components outside of the Framework.</p>

<p>This RFC is designed to answer some of the questions around removing the old Zend_Service classes from the Framework, and converting them to their own components. In addition to the base RFC; this RFC <strong>should be</strong> transferable to modules / components that <strong>may not be</strong> maintained in the framework. This allows the building or leveraging of an existing infrastructure much like PECL/PEAR/Pyrus/Composer to where non-core components <strong>may be</strong> maintained underneath the ZF umbrella as a certified component / module.</p>

<ul>
<li>Components <strong>must be</strong> moved out from the Zend\Service component namespace except where:
<ul>
<li>&quot;Core&quot; framework components have dependencies on it</li>
<li>The component needs to stay in the core repository for marketing or political reasons</li>
</ul>
</li>
</ul>


<ac:macro ac:name="info"><ac:rich-text-body><p>One of the main components in this exception is Zend\Cloud which relies on various Service API's. An alternative to this would be to throw an exception to state to install the missing component.</p></ac:rich-text-body></ac:macro>

<h3>Goals</h3>
<ul>
<li>Can version separately from the main library, allowing updates when APIs are updated vs when the next ZF release happens</li>
<li>Easier for developers to install separately from the framework (though many depend on Zend\Http, Zend\Rest, and/or Zend\Uri)</li>
<li>Separation may encourage service providers to further contribute services for their API's</li>
</ul>


<h3>Components</h3>

<ul>
<li>Components <strong>should be</strong> independently versioned rather than having to ship with a ZF release
<ul>
<li>This reduces the possibility of having to bundle a new ZF release when API compatibility or new features become available</li>
</ul>
</li>
<li>Components <strong>must be</strong> versioned by framework version for dependency management to ensure compatibility with the installed ZF2 version</li>
<li>Components <strong>must be</strong> able to state dependencies ensuring ease on the end developer in installation of the said component</li>
<li>Components <strong>should be</strong> installed within the &quot;vendors&quot; directory (recommended strategy) much like ZF2</li>
<li>Components <strong>must be</strong> in their own namespace, and have a parent namespace that is different than the &quot;Zend&quot; namespace; Services in particular would be &quot;Zend*\Service&quot; where the * would be replaced with the namespace.
<ul>
<li>This allows for further expansion later on for additional components</li>
</ul>
</li>
<li>Components <strong>must</strong> follow the same coding standards as a core component
<ul>
<li>Coding Conventions</li>
<li>Unit Tests</li>
<li>Documentation</li>
<li>Demos (</li>
</ul>
</li>
<li>Official components <strong>must be</strong> under the &quot;ZendFramework&quot; organization in GitHub
<ul>
<li>Maintainers will <strong>not</strong> be given direct write access to the component but instead issue pull requests - this allows for code reviews.</li>
</ul>
</li>
<li>Components <strong>may</strong> depend on other core components or official components (official meaning that they are under the zendframework organization)</li>
</ul>


<h4>Component Lifecycle</h4>

<ac:macro ac:name="note"><ac:rich-text-body><p>The following assumes a dependency manager; Pyrus and/or <a href="http://getcomposer.org/">Composer</a> could be used (a mixture leveraging a bridge script to take composer files and translate to Pyrus may be an option).</p></ac:rich-text-body></ac:macro>

<ol>
<li>Components may be created by filling out a web-form that asks about the component (name, description, what it does and dependencies) and the individual (github username at a min).
<ol>
<li>In the future it would be nice to automate this step through the use of a custom system; however, it may be necessary to send an email in the beginning.</li>
</ol>
</li>
<li>An email will be sent to the CR team for approval
<ol>
<li>It is necessary that the component must be already in active development with some level of stability and/or usage.</li>
</ol>
</li>
<li>The CR team may accept, deny or ask for additional feedback.
<ol>
<li>No duplicate components should be accepted; it <strong>must be</strong> encouraged to contribute rather than replace.</li>
</ol>
</li>
<li>If the component is accepted; a github repository is created.
<ol>
<li>The maintainer should now fork the component and issue pull requests; thus allowing code review.</li>
</ol>
</li>
<li>Once a component is ready; a composer.json package file should be added.
<ol>
<li>Versioning should follow the <a href="http://getcomposer.org/doc/02-libraries.md#specifying-the-version">composer model</a></li>
</ol>
</li>
</ol>


<h5>Maintainer Semantics</h5>

<ul>
<li>A component <strong>must be</strong> maintained for the duration of major versions
<ul>
<li>In case of an exception where compatibility will not be maintained; it must be noted in the ZF ChangeLog</li>
<li>Additionally; a component must only state dependency on a particular minor version to prevent issues in BC.</li>
</ul>
</li>
<li>JIRA will have a Project for Zend Components<br />
**Accepted components will have a component made under the project for issue tracking<br />
**Maintainers will be added to the component as the Lead</li>
<li>While maintainers (authors) may have the best intentions to keep their package up-to-date; these maintainers may no longer be in a position to maintain the component. In this case; a new maintainer will actively recruited, if one is not found the ZF team and/or CR team will make a recommendation to maintain / deprecate or remove the component.</li>
<li>Documentation should be generated along with the main documentation or as a subset of the current documentation.</li>
</ul>


<h3>Work to be Completed</h3>

<ul>
<li>Component Page on WIKI explaining process &amp; proposals
<ul>
<li>Optionally building a separate application to automate this to live on zendframework.com (proposals.zendframework.com)</li>
</ul>
</li>
<li>Refactor existing Zend\Service components to new GH repositories</li>
<li>Integration with packages.zendframework.com</li>
</ul>


<h3>Open Questions</h3>

<ul>
<li>What dependency management system should be utilized?
<ul>
<li>Composer works great for this type of system; but Pyrus is the preferred distribution
<ul>
<li>Does a bridge make sense to be built for this case?</li>
<li>Would we need to improve Pyrus for this use case?</li>
</ul>
</li>
</ul>
</li>
<li>Where should these components live in terms of find-ability?
<ul>
<li>We could likely build out a new area on packages.zendframework.com to contain the packages.
<ul>
<li>Ideally; it should state the maintainer(s), available version(s), documentation, etc.</li>
</ul>
</li>
</ul>
</li>
<li>Should these components be bundled in a full-blown ZF package?
<ul>
<li>There are pro's and con's to this approach, and on a practicality level; I don't think they should be</li>
</ul>
</li>
<li>Is there a CI server where components may be unit tested?
<ul>
<li>What component versions should be tested for compatibility?
<ul>
<li>Recommended that we would test all versions that have matching versions of the component against current ZF2 master in order to show possible breaks in components. Additionally the master branch of the component would be tested against ZF2 master.</li>
</ul>
</li>
</ul>
</li>
<li>How does a component maintainer become notified of a BC break?
<ul>
<li>This may be solved by having a CI server running unit tests against ZF2 master and notifying maintainers of the project.
<ul>
<li>This could cause false positives; but may aide in communication.</li>
</ul>
</li>
</ul>
</li>
</ul>