Skip to end of metadata
Go to start of metadata

<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>"Core" 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 "vendors" 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 "Zend" namespace; Services in particular would be "Zend*\Service" 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 "ZendFramework" 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 & 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>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Mar 19, 2012

    <p>Another issue brought up during the meeting: should they be moved to <em>modules</em>, or simply packaged as library components? In other words, if it's mainly library code, should we be encouraging packaging something as a module, or only encourage that for code that needs to integrate with MVC applications?</p>

    1. Mar 20, 2012

      <p>I think in this case specifically; that they should simply be packaged as library components; I think that we can promote modules another way as a community forge style site. The bigger thing here is that there will likely be several "components" that the community may want and integration of said components into an application should be put together as a separate module. </p>

      <p>The huge thing in my mind is that I generally don't want someones implementation of a component but the component itself; which brings implementation details down to a module and the generalities being the component.</p>

    2. Mar 21, 2012

      <p>I have an outstanding blog topic on this somewhere, but long story short. The only reason to ever use the Module architecture is if the code the Module packages is unquestionably dependent on using Zend Framework's MVC. Code not dependent on using the MVC should never be in a Module. By that simple set of rules, service components don't belong in Modules for the simple reason - they don't need Modules in order to be usable. Let's not make the same repetitive mistake of using Modules as a neat excuse to make useful code require Zend Framework MVC - I'm sure I'm not the only ZF user who dabbles with other frameworks and would prefer clean reusable unencumbered code.</p>

  2. Mar 21, 2012

    <blockquote><p>Bugs should be tracked through the GitHub issue tracker not through the JIRA issue tracker since these are non-core components.</p></blockquote>

    <p>Does it mean: 10 service components == 10 issue tracker? That would be a bad idea.<br />
    A separate project for all components together in the JIRA issue tracker would be better.</p>

    1. Mar 21, 2012

      <p>Thanks for the feedback; I agree that it might be slightly more difficult to have them in each github project and it was more or less an attempt to try and keep JIRA a bit more focused. </p>

      <p>Another option I suppose would be:<br />
      JIRA will have a Project for Zend Components</p>
      <ul>
      <li>Accepted components will have a component made under the project for issue tracking</li>
      <li>Maintainers will be added to the component as the Lead</li>
      </ul>

      1. Mar 21, 2012

        <p>I think it's important we stick to JIRA. ZF1 has been a good teacher in that the only way to handle maintenance is to bring some focus to the table. With JIRA, the CR Team can, eventually when we can commit actual time, monitor maintenance a lot more religiously than in the past. Even the small window of time I had with ZF1 to refocus maintainance has almost eliminated the Blocker and component-breaking issues (Adam Lundrigan has done more than me in this area TBH since I started!).</p>

        <p>Monitoring over multiple git repos will be a lot harder, and Github's issues aren't perfect for large projects like ZF where monitoring and filters can be a huge help.</p>

        1. Mar 21, 2012

          <p>Sounds good; I will update the RFC after all of the feedback has come in to address this.</p>

      2. Mar 21, 2012

        <blockquote>
        <p>JIRA will have a Project for Zend Components</p>

        <ul class="alternate">
        <li>Accepted components will have a component made under the project for issue tracking</li>
        <li>Maintainers will be added to the component as the Lead</li>
        </ul>
        </blockquote>
        <p>Full agreement!</p>