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.)
