Skip to end of metadata
Go to start of metadata

<p>The following is the proposed structure for an SVN repository reorganization, pursuant to providing differentiation between components that receive Zend support (standard) and those that do not (extras). This also incorporates and supersedes the currently separate laboratory repository.</p>

<ac:macro ac:name="info"><ac:parameter ac:name="title">Standard vs. Extras</ac:parameter><ac:rich-text-body>
<p>Components in the "extras" tree are held to the same quality standards that apply to the "standard" library. That is, such components, in order to be promoted from the extras incubator, must have unit tests with code coverage of at least 80% (100% being a goal), documentation that covers all features, and coding standards compliance (including docblocks). The difference is that "extras" components would not be included for Zend support customers, whereas components in the "standard" library are included with Zend support.</p></ac:rich-text-body></ac:macro>

<ac:macro ac:name="tip"><ac:parameter ac:name="title">Sparse Checkouts in SVN 1.5</ac:parameter><ac:rich-text-body>
<p>The ability to checkout various portions of a repository as a single working copy, also known as "sparse checkouts", is <a href="http://subversion.tigris.org/roadmap.html">planned to be supported in Subversion 1.5</a>. For example, if you wanted to checkout the standard incubator library and tests, the standard trunk library and tests, and only the English version of the documentation in a single working copy, you would be able to do this once we have adopted SVN 1.5; however, it will be dependent on using a client that is compliant with SVN 1.5 as well. <ac:emoticon ac:name="smile" /></p></ac:rich-text-body></ac:macro>

<ac:macro ac:name="noformat"><ac:plain-text-body><![CDATA[
standard/ (supported by Zend)
branches/ (branches of standard/trunk/, e.g., for release candidacy, maintenance)
release-1.0/
release-1.5/
release-2.0/
incubator-tool/
tags/ (tags of standard/branch/* for all but documentation, which comes from standard/trunk/)
release-1.0.4/
release-1.5.1/
release-2.0.0/
incubator-tool-1.6.0RC1/
trunk/ (main development line for Zend-supported components)
documentation/
manual/
INSTALL.txt
LICENSE.txt
UPDATING.txt
library/
Zend/
tests/
Zend/
incubator/ (special, contents are intended to be promoted to standard/trunk/ when ready)
documentation/
library/
Zend/
tests/
Zend/
extras/ (community supported, not supported by Zend)
branches/ (branches of extras/trunk/, e.g., for release candidacy, maintenance)
release-2.0/
incubator-zend-foo/
tags/ (tags of extras/branch/* for all but documentation, which comes from extras/trunk/)
release-2.0.0/
incubator-zend-foo-1.9.0/
trunk/ (main development line for extras components)
documentation/
library/
ZendX/
tests/
ZendX/
incubator/ (special, contents are intended to be promoted to extras/trunk/)
documentation/
library/
ZendX/
tests/
ZendX/
laboratory/ (contents are not currently intended to be included in standard/ or extras/)
someMvcModule/
branches/
tags/
trunk/
magicProject/
branches/
tags/
trunk/
someComponent/
branches/
tags/
trunk/
library/
ZendL/
tests/
ZendL/
build-tools/ (moved from standard/trunk/build-tools/ and standard/trunk/scripts/)
]]></ac:plain-text-body></ac:macro>

<h3>Notes</h3>
<p>Incubators are intended for development of new components or refactoring of existing components in a given subproject. As such, they are semantically tied to that subproject. In all cases, incubators follow the same project structure as their subproject, and include documentation, library, and tests directories mirroring those of the trunk. When development is complete – test coverage and documentation meets standards – they will be promoted to trunk for their given subproject.</p>

<p>Branches and tags can and will contain branches and tags of both incubator and trunk; the differentiation will be via naming conventions. Some examples are included in the above schema.</p>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. May 15, 2008

    <p>First of all I would rename 'branch' and 'tag' directories to follow subversion conventions of naming them 'branches' and 'tags' respectively. This will allow for better integration with the tools like Subversive (I'm not sure if it could detect singular forms as it detects plural).</p>

    <p>Secondly, this scheme seems pretty complicated. If you wish to keep the incubators then there should be a way to tag the changes in them as well as branch from time to time. What I propose is to bring them closer to the surface instead of burying them in extras and standard branches. Maybe it would be better to keep them at the "project" level (see structure below)</p>

    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    standard/
    branches/
    release-1.0/
    tags/
    release-1.0.4/
    trunk/
    documentation/
    library/
    Zend/
    tests/
    Zend/
    standard-incubator/
    trunk/
    documentation/
    library/
    Zend/
    tests/
    Zend/
    branches/
    tags/

    extras/
    branches/
    tags/
    release-2.0.0/
    trunk/
    documentation/
    library/
    ZendX/
    tests/
    ZendX/
    extras-incubator/
    trunk/
    documentation/
    library/
    ZendX/
    tests/
    ZendX/
    branches/
    tags/
    (...)
    ]]></ac:plain-text-body></ac:macro>

    <p>Furthermore, I'm in rage when I have to wait for a documentation synchronization on svn update after a longer period of time. It's so much time wasted! No to mention svn switch or anything similar. Wouldn't it be possible to move it to it's own folder? Especially when you have translations there which aren't going to be used by a single developer anyway.</p>

    1. May 15, 2008

      <blockquote><p>First of all I would rename 'branch' and 'tag' directories to follow subversion conventions of naming them 'branches' and 'tags' respectively.</p></blockquote>

      <p>+1</p>

  2. May 15, 2008

    <p>Does this mean that extras and standard will follow separate release schedules? It would appear likely that this would happen with this scheme.</p>

    <p>I also agree and tags/ and branches/</p>

    <p>Rob...</p>

  3. May 15, 2008

    <p>You can set the names for 'branches', etc in the Subversive prefs IIRC. However, using standard conventions trumps customization every time, in my opinion.</p>

  4. May 15, 2008

    <p>I don't care either way about the branches/tags or branch/tag. I use branch and tag (singular) for my own svn repos too, never caused me any trouble.</p>

    <p>I'm not liking Michal Minicki's vision of the incubators. The way I read his comment was that his proposal is to make this less complicated? I don't think adding more directory levels makes things less complex. And, just because something is in a branch doesn't mean that you can't branch it. So, if there really was a need to branch the incubator, go ahead, just a copy in svn. Same goes with tags.</p>

    <p>Furthermore, I disagree with Michal Minicki about the documentation gripe. Sure, most developers won't be doing documentation translations, but doing your own documentation should always be encouraged. If the documentation directory is not even part of your working copy, then it makes it that much easier for a developer to ignore.</p>

    <p>Anyway, if you can't tell, I think Darby's proposal is fine, I just wanted to comment about some of the other ideas here.</p>

  5. May 17, 2008

    <p>I still prefer "extensions" to "extras". ZendX is just so... lame.</p>

    <p>The incubator isn't really a branch. You don't have a copy of the entire standard library in there. It's mostly new development.</p>

    <p>To me, this seems like the most logical directory structure:</p>

    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    branches/
    release-1.0/
    tags/
    release-1.0.4/
    trunk/
    standard/
    documentation/
    library/
    Zend/
    tests/
    Zend/
    standard-incubator/
    documentation/
    library/
    Zend/
    tests/
    Zend/
    extension/
    documentation/
    library/
    ZendExt/
    tests/
    ZendExt/
    extension-incubator/
    documentation/
    library/
    ZendExt/
    tests/
    ZendExt/
    laboratory/
    (...)
    ]]></ac:plain-text-body></ac:macro>

    <blockquote>
    <p>Furthermore, I'm in rage when I have to wait for a documentation synchronization on svn update after a longer period of time. It's so much time wasted! No to mention svn switch or anything similar. Wouldn't it be possible to move it to it's own folder? Especially when you have translations there which aren't going to be used by a single developer anyway.</p></blockquote>

    <p>Documentation has to stay with the code in case of branches.</p>

    <p>(Edited to change Zend_Ext to ZendExt per Tony Ford's comments.)</p>

    1. May 15, 2008

      <blockquote>
      <p>Documentation has to stay with the code in case of branches.</p></blockquote>
      <p>+1</p>

      <p>I must admit I don't like ZendX prefix either although I cant think of something both short and nice.</p>

    2. May 16, 2008

      <p>I like Matthew R.'s proposed layout; makes more sense, IMHO.</p>

    3. May 16, 2008

      <p>Great folder structure, Matthew! Clean and easy to grasp. I like it even better than my own version.</p>

    4. May 16, 2008

      fc

      <p>+1, I'm with Matthew on this one. I like the directory structure he's proposing, and IMO Zend_Ext is far more descriptive and elegant than ZendX.</p>

    5. May 20, 2008

      <p>Calling it "lame" means nothing. What is "lame" about it? Other projects use the 'X' notation for extras/extensions, and the ZendX is shorter and leads to a shallower directory structure than 'Zend_Ext'. While ZendExt would work, it's verbose; however, I'm willing to concede to that particular name.</p>

      <p>As for your comments about incubator as not "really a branch", I respectfully disagree. It is our <em>development</em> branch for new features. Branches do not need to be complete copies of trunk; they are often used for parallel development and isolated development of new features, and the incubator fits both of these descriptions. Additionally, there are times we want to branch development of components in the library to do so without affecting developers using trunk; incubator is the place to do this. By having an incubator branch in each project, we also gain the ability to clearly delineate which features are upcoming or undergoing refactoring for that particular project. It also allows us to prepare documentation for these new components.</p>

      1. May 21, 2008

        <blockquote><p>Calling it "lame" means nothing. What is "lame" about it?</p></blockquote>

        <p>It sounds like the snowboarding love child of Mountain Dew and Zend. But more seriously, ZendX is vague and meaningless. "ZendExt" is much less ambiguous and communicates the intention of the namespace much more clearly.</p>

        <blockquote><p>While ZendExt would work, it's verbose</p></blockquote>

        <p><ac:image><ri:attachment ri:filename="crocodile-dundee-screenshot-you-call-that-a-knife11.jpg" /></ac:image></p>

        <p>"Zend_Search_Lucene_Analysis_Analyzer_Common_Utf8Num_CaseInsensitive"</p>

        <p>Given names like these, I'm sure two additional characters won't be too much of a burden. <ac:emoticon ac:name="wink" /></p>

        <blockquote><p>As for your comments about incubator as not "really a branch", I respectfully disagree.</p></blockquote>

        <p>I can see your point about incubator-as-a-branch, but what happens if someone wants to branch an incubator component (for example, two alternate implementations, branching an inactive incubator component for a redesign, etc.)? OK, that may be an unlikely case. If you think so, then I think having it as a branch would be OK.</p>

        1. May 21, 2008

          <p>Agreed, ZendExt vs ZendX is but two characters. However, see my point in another comment as well: withthe announcement of the Dojo partnership, there's an additional, consistency rationale: Dojo utilizes DojoX for their extras library, and naming ours likewise shows affinity and consistency with what they are doing.</p>

          <p>Regarding the incubator as a branch argument, please view the revised layout, which shows incubator on the same level as trunk. We feel this is a reasonable compromise – it allows branching incubator components (unlikely to occur, but it allows us to do so reasonably), and also provides a clear indication that the "branch" is long-lived and supported (as branches are often, correctly or not, considered temporary in nature).</p>

  6. May 17, 2008

    <p>I think there are some great ideas and thoughts expressed <ac:emoticon ac:name="smile" /></p>

    <p>I thought about this a lot more after reading the latest comments here and even took a look at some svn docs and how the apache foundation organizes their garganchuan repository. I concluded that we should take a little bit of something from everyone that has commented here, suggestions from the subversion team, some insight from apache, and of course spin it so it actually fits the ZF project(s) and goal here. Here are some of my proposals/ideas:</p>

    <ol>
    <li>I like projects at the top level of the repository best. When I'm looking at a repository, the first thing I want to look at is the "project" I'm interested in. Why should I have to choose trunk, branches, or tags, then find my project, then maybe have to go back and look at another top level directory again. If you look around at repositories you'll find most have projects at the top level, then trunk, branch and tag directories under each project.</li>
    <li>Change /branch and /tag to the subversion convention of /branches and /tags. Honestly, this doesn't matter too much, but its an svn convention, and this is a great time to change it.</li>
    <li>Change "extras" to "extensions". Extra seems to diminish the importance of the extra libs. Extension sounds more powerful, and something I'd be interested in using to make my library "better" vs "just bigger". Furthermore, this is more in line with terminology used for php itself. PHP has the standard library and other extensions included in the core that get wrapped up in the release packages, and then there is PECL.</li>
    <li>I also somewhat agree with Matthew on the ZendX lib directory name. Using a sub directory like he shows isn't going to work real well and doesn't make sense in my opinion. I think most people using ZF will have a main "library" directory where they might have other packages along next to the "Zend" directory. So I quite like a different name for the extensions, but let's use ZendExt instead of ZendX.</li>
    <li>The incubator should be setup just like Darby's suggestion for the laboratory. The incubator is just a special place to work on normal projects, so put all those normal projects under one incubator. It does not make sense always having a special incubator branch. I want to be able to look at the incubator from the top level of the repository, just like any other project. Inside of the top level of the incubator I should be able to choose a project.</li>
    </ol>

    <p>All that being said, here's the structure I propose:</p>

    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    standard/ (supported by Zend)
    branches/ (branches of standard/trunk/, e.g., for release candidacy, maintenance)
    release-1.0/
    release-1.5/
    release-2.0/
    tags/ (tags of standard/branch/* for all but documentation, which comes from standard/trunk/)
    release-1.0.4/
    release-1.5.1/
    release-2.0.0/
    trunk/ (main development line for Zend-supported components)
    documentation/
    manual/
    INSTALL.txt
    LICENSE.txt
    UPDATING.txt
    library/
    Zend/
    tests/
    Zend/
    extensions/ (community supported, not supported by Zend)
    branches/ (branches of extensions/trunk/, e.g., for release candidacy, maintenance)
    release-2.0/
    tags/ (tags of extensions/branch/* for all but documentation, which comes from extensions/trunk/)
    release-2.0.0/
    trunk/ (main development line for extensions components)
    documentation/
    library/
    ZendExt/ (A different name under the library dir so it can be easily installed along side the standard Zend dir)
    tests/
    ZendExt/
    incubator/ (contents are intended to be promoted to other top level projects)
    standard/ (standard project incubator)
    branches/
    someComponent/
    tags/
    trunk/
    documentation/
    library/
    Zend/
    tests/
    Zend/
    extensions/ (extensions project incubator)
    branches/
    someComponent/
    tags/
    trunk/
    documentation/
    library/
    ZendExt/
    tests/
    ZendExt/
    laboratory/ (contents are not currently intended to be included in standard/ or extensions/)
    someMvcModule/
    branches/
    tags/
    trunk/
    magicProject/
    branches/
    tags/
    trunk/
    someOtherProject/
    branches/
    tags/
    trunk/
    build-tools/ (moved from standard/trunk/build-tools/ and standard/trunk/scripts/)
    ]]></ac:plain-text-body></ac:macro>

    1. May 17, 2008

      <p>I like this proposal. Having projects top-level gives a better overview in my opinion. Also, as other people have said, now is a good time for changing to 'tags' and 'branches'.</p>

      <p>I'm not sure if I like having INSTALL.txt and LICENSE.txt in the 'documentation' sub folder. In my mind, you should be able to to 'svn co /some/trunk', then just do 'cat INST' and press tab. Same goes for license.</p>

    2. May 17, 2008

      <p>I agree with the above comments.</p>

      <p>I'm getting into svn these days and I found that having all the projects in the same directory and then having the three standard (trunk, branches and tags) directories as subfolders seems better in terms of organisation.<br />
      Having all projects mixed in branches and tags (and trunk) directory could become hard to mantain because of the different snapshots of the various projects, and is much prone to errors, specially when branching or merging projects.</p>

    3. May 17, 2008

      <p>Whether or not to have trunk, branches, and tags at the root level or not is really a matter of opinion, I think. It comes down to whether you view the standard library, extensions, etc. as different projects or part of one. I view them as part of one: Zend Framework.</p>

      <p>Your comment about ZendExt vs. Zend_Ext is absolutely right and so I've updated my layout to reflect that.</p>

      1. May 18, 2008

        <p>Matthew, I basically agree that it is mostly a matter of personal opinion, but I also believe there is a small advantage in convenience when you have projects at the top level.</p>

        <p>Say I was going to be working on something that lives in the extension section of the repository. With trunk, branches, and tags at the top level of the repository, I have to go back and forth and be somewhat bothered by other directories that are of no interest to me. If I expand the trunk, I have to see all the other stuff, just to get to "extensions". Then what if I need to look at a branch? Same thing. On the other hand, if all the different projects are at the top level, and have their own trunk, branches, and tags dirs, then I only need to expand the extensions project, and I can easily work only on that project. Works better for checkouts too. Although, as Darby added to this wiki doc, svn 1.5 will make our lives easier in that regard.</p>

        <p>Also, I actually agree with you that everything is part of one project: ZF. The "repository" is for the project named "Zend Framework", and inside that project lives many separate sub-projects. So in my mind, I do view all the projects as one, and also believe the structure I proposed makes sense too.</p>

    4. May 20, 2008

      <p>I very much disagree with having incubator as a separate subproject. Components will be approved for standard incubator or extensions incubator – i.e., they <em>belong</em> to those particular subprojects. Think of incubator as a <em>development</em> branch for that project – it could contain new functionality, or functionality that has been forked briefly for development purposes in order to keep a stable trunk for the given subproject. This allows us to keep all development for a given component within the same subproject in which it will appear for general release.</p>

      1. May 20, 2008

        <p>I see your point, but on the other hand, by its very nature, the incubator has nothing to do with the standard and extensions sub-projects. i.e. Even though work in the incubator is "intended" to be merged into standard, extensions, or subproject n, nothing in the incubator at any given time is actually apart of those sub-projects.</p>

        <p>This is the whole point. The incubator is a completely abstracted area of the repository where development takes place before it gets committed to the trunk of "real" (for lack of a better term) projects. Sure, parts or all of an incubator project could be a branch of a real project, but that doesn't mean it belongs as a branch in that project.</p>

        <p>Honestly, I'm not trying to draw a hard line here, I'm just trying to give you my perspective, as best I can. Maybe I had already done that, but I thought it was worth a more in depth explanation. At the end of the day, a branch would work out ok, I just think this makes a little bit more sense.</p>

        1. May 21, 2008

          <p>Here's another perspective: the individual contributor. Let's say we have DevX, who is working solely on Zend_Controller_Dispatcher. With incubator as a branch of the 'standard' subproject, DevX can check out <em>only</em> that subproject – when they are done making their additions or changes, they can merge.</p>

          <p>With 'incubator' as a separate subproject, until subversion 1.5.0 is released and in wide usage and sparse checkouts are allowed, DevX now needs to checkout the <em>entire</em> project, not just the subproject, in order to be able to merge from incubator to standard when development is complete. This represents a lot of overhead to the developer – extra bandwidth, extra disk usage, etc. And all they want to do is hack on the standard library – not extras, not laboratory, not tools.</p>

          <p>This alone is a good reason to keep incubators within each subproject. Add to that the idea of keeping incubator components semantically close to their subproject, and the idea of removing code and tree duplication (an incubator subproject duplicates tree structures), having a separate incubator subproject makes less and less sense.</p>

  7. May 21, 2008

    <p>Although you bring up a good point about inconvenience, that's not 100% true.</p>

    <p>I can checkout two separate sub-projects and merge in between the two with svn merge. So yes, I would have to maintain 2 separate working copies of two different directories, vs just checking out the standard project, but I can merge the same in either case.</p>

    <p>I think there are points to be made for either solution. I won't be unhappy with either.</p>

  8. May 21, 2008

    <p><strong>On the subject of ZendX vs. ZendExt/Zend_Ext</strong></p>

    <p>The reasoning behind the verbiage of "Extras" instead of "Extensions" is:</p>
    <ul>
    <li>"Extension" implies that you are extending something. This doesn't necessarily reflect what is actually going into this category. Components that live in this namespace are just a susceptible to the use-at-will architecture and philosophy as Zend Standard library components. Also, while components can have minimal dependencies with other components in the standard library, we wish to not imply that classes in this category of components will be "extends"(ing) classes in the standard library as their very nature.</li>
    <li>"Extension" is a loaded word in php. Currently, php extensions are typically defined as language extensions that exist in PECL.</li>
    <li>Typing. For components that we expect to be used at-will and out of the box (so to speak), its important that we keep namings short and sweet as much as humanly possible.. at least until PHP5.3 Namespaces are usable by the framework. ZendX is simply shorter than ZendExt and Zend_Ext.. and there is no real loss of meaning in its shortness/conciseness.</li>
    </ul>

    <p>In general, ZendX/"Zend Extras" tell the best story we can tell with respect to what the goal of this collection of components actually is.</p>

    1. May 21, 2008

      <p>One other thing to note, in light of the new partnership with Dojo... Dojo ships its 'extras' in DojoX. Using ZendX presents a consistent message to developers who utilize both ZF and Dojo.</p>

      1. May 21, 2008

        <blockquote><p>"Extension" implies that you are extending something. This doesn't necessarily reflect what is actually going into this category. Components that live in this namespace are just a susceptible to the use-at-will architecture and philosophy as Zend Standard library components. Also, while components can have minimal dependencies with other components in the standard library, we wish to not imply that classes in this category of components will be "extends"(ing) classes in the standard library as their very nature.</p></blockquote>

        <p>First, I'd like to say that I still favor Standard Library and Community Library. I think that's the best overall name. But Community is hard to shorten for a namespace, which is why I thought "Community Extensions" and then just "Extensions". <ac:emoticon ac:name="smile" /></p>

        <p>But regarding "Extension". I view it as extending the functionality of Zend Framework, not the classes themselves. "Extensions" is a common synonym for "add-ons".</p>

        <blockquote><p>"Extension" is a loaded word in php. Currently, php extensions are typically defined as language extensions that exist in PECL.</p></blockquote>

        <p>That's true. Community Library wouldn't conflict with that nomenclature.</p>

        <blockquote><p>Typing. For components that we expect to be used at-will and out of the box (so to speak), its important that we keep namings short and sweet as much as humanly possible.. at least until PHP5.3 Namespaces are usable by the framework. ZendX is simply shorter than ZendExt and Zend_Ext.. and there is no real loss of meaning in its shortness/conciseness.</p></blockquote>

        <p>Again, Zend_Search_Lucene_Analysis_Analyzer_Common_Utf8Num_CaseInsensitive. Given names like these that already exist in the framework, two extra characters do not seem like that big of a deal.</p>

        <p>If character length is a factor, we should apply the same rigorous standards to all of our class names. Why Zend_Filter_StringToUpper instead of Zend_Filter_Strtoupper? Why getInstance() instead of instance() or inst(), both of which are much more common than getInstance(), according to Google Code Search?</p>

        <p><a class="external-link" href="http://www.google.com/codesearch?hl=en&lr=&q=%3A%3Ainst%28%29&sbtn=Search">http://www.google.com/codesearch?hl=en&amp;lr=&amp;q=%3A%3Ainst%28%29&amp;sbtn=Search</a>
        <a class="external-link" href="http://www.google.com/codesearch?hl=en&lr=&q=%3A%3Ainstance%28%29&sbtn=Search">http://www.google.com/codesearch?hl=en&amp;lr=&amp;q=%3A%3Ainstance%28%29&amp;sbtn=Search</a>
        <a class="external-link" href="http://www.google.com/codesearch?hl=en&lr=&q=%3A%3AgetInstance%28%29&sbtn=Search">http://www.google.com/codesearch?hl=en&amp;lr=&amp;q=%3A%3AgetInstance%28%29&amp;sbtn=Search</a></p>

        <blockquote><p>One other thing to note, in light of the new partnership with Dojo... Dojo ships its 'extras' in DojoX. Using ZendX presents a consistent message to developers who utilize both ZF and Dojo.</p></blockquote>

        <p>"DojoX is the incubator for many truly innovative ideas - from DojoX Wires to Dojo Offline - many of which will find their way into the Dojo Core or Dijit." Another section calls the components in it "experimental".</p>

        <p>Because components migrate from DojoX to Dojo Core or Dijit, DojoX is more like our incubator. I think a parallel name would only confuse things.</p>

        1. May 21, 2008

          <p>DojoX is analogous to both our incubator as well as what we're considering our 'Extras' library. We may at some point choose to merge a ZendX component to the standard library, if it has wide community support or falls in line with other components we offer – and this is where it directly correlates with DojoX. The delineation we're making is as to what we call our standard library, which we support and which is shipped with every release, and the other offerings we provide without direct support from Zend and which may or may not be shipped based on the release package selected by an end user.</p>

          <p>I like the idea of "Community Library", but this is not just community contributions; I have a few components lined up myself that will likely be in this library. As such, its a misnomer.</p>

          <p>Let's face it, no matter what we decide on here, there will be people arguing against it. We're choosing ZendX, as it clearly denotes a separate quasi namespace, denotes 'eXtras' briefly, and still indicates its relationship to the Zend Framework project.</p>

  9. May 21, 2008

    <p>What are standard/incubator-tool/ and standard/incubator-tool-1.6.0RC1/ ?</p>

    1. May 21, 2008

      <p>Indentation issues – they were meant to be under branches and tags, respectively. I've updated the document to show the correct layout.</p>