Hi Gavin, Points 2 through 6 all make good sense to me, and would / are valuable distribution methods.
I understand the difficulty with point 1 as you outlined. Personally, I find segmenting young, experimental code in the incubator dir tree unnecessarily difficult to work with. From what I can tell, it makes including only certain components from the incubator, and not all, hard or impossible to manage. To be sure, it's not clear to me how dependencies between incubator components and core components are to be handled, and if one needs to adopt the entire incubator tree over the core tree if one want to use certain incubator components. Am I not understanding on how this should work, or is this an issue related to component versioning? Thanks, Mike -----Original Message----- From: Gavin Vess [mailto:[EMAIL PROTECTED] Sent: February 2, 2007 6:05 PM To: [email protected]; Andries Seutens Subject: Re: [fw-general] PEAR Channel Distro I see much value in each of the following scenarios, which combined form what I expect to cover the majority of use cases: 1) PEAR "component" distributing entire ZF (for developers interested primarily in the latest official release of the incubator, docs, and tests, with an easy mechanism to update to a future official release). 2) PEAR "component" distributing only the stable, production-ready code tree (for easy deployment to production servers) 3) SVN checkout of the entire ZF (for developers interested in the latest and greatest incubator, docs, and tests) 4) Downloadable tarballs/zip archives for those in a hurry, who want a specific release once and no updates. 5) Downloadable nightly snapshots for those who one to make a one-time evaluation/analysis of the latest versions of everything in our source code repository. 6) Online docs - I have a personal bias due to a belief that online documentation usually enables more rapid and frequent updates, user comments and contributions, and ease of use, thus resulting in greater developer productivity. Developers doing actual development probably want #1 or #3 for the reasons Matthew lists below. My personal preference for deploying to production servers is #2. Unfortunately, when we look at the directory structure (zftrunk/library/Zend and zftrunk/incubator/library/Zend) in combination with the conventions of PEAR components, combining both into a single PEAR component (i.e. #1 above) becomes slightly problematic, so #1 might not result in a convenient layout for some. I suggest we start with implementing #2 first by updating and finishing the system started at http://pear.zfdev.com/. Cheers, Gavin Matthew Weier O'Phinney wrote: > -- Rob Allen <[EMAIL PROTECTED]> wrote > (on Friday, 02 February 2007, 06:42 AM +0000): > >> Michael Caplan wrote: >> >>> Being a newbie, perhaps I am overlooking something here, but I don't >>> understand your comment that "The Zend Framework works together, as a >>> complete unit." I understand their are various component dependencies, >>> but I don't believe that I can't use Zend_Pdf, for example, if the >>> _entire_ framework is not installed. If PDF generation is my goal, I >>> don't care to have to install 15MB of framework just to use that piece. >>> If anything I see that as being an inhibitor for framework use, >>> especially as the core framework size grows (and it is, isn't it?). >>> >>> >> Personally, I think that we should consider packaging up just library/ >> for each release in addition to the entire caboodle that we do at the >> moment. >> >> Certainly, on our production servers, we don't need demos/ >> documentation/, incubator/ or tests/. >> > > Just a note: most PEAR packages contain, minimally, tests, and often > documentation and examples. Granted, however, the ZF documentation is > the larger part of the install, so it may make sense to have it > available separately. > > (It's good to have the tests available, as you may run them on an > architecture different than those developing a component, which may > expose new errors. Additionally, tests show you how the code is intended > to work.)
