Re: [PHP-PEAR] Re: [PHP-CVS] cvs: php4 /pear/Experimental README/pear/Experimental/HTML Menu.php

NB!  Reply-to: set to [email protected]!

[Sebastian Bergmann <[email protected]>]
> Ulf Wendel wrote:
> > uw              Fri Mar  9 00:54:01 2001 EDT
> > 
> >   Added files:
> >     /php4/pear/Experimental     README
> >     /php4/pear/Experimental/HTML        Menu.php
> >   Log:
> >   Added a directory Experimental/ as no one said "no" on the PEAR list
> >    - added a PHPlib menu2.inc rewrite
> >    - added a README for the directory with a policy for Experimental/
> 
>   I like the idea, Ulf.
> 
>   Chuck - Stig, should Experimental/ be added to Makefile.in?

Actually, if we start going down this route we might as well move all
the code to the "pear" CVS module and get to the next level.

Below are some ideas on how to use the php.net-supplied CVS module:

1. New CVS module file structure

I think the new CVS module should be structured by package names,
rather than like a hierarchy like it is today.  The hierarchy will be
used when files are installed.

Package names are almost like class names, but if the package contains
a lot of classes, the "root" class is used.  For example, PEAR DB's
package name would be "DB", because its root class is called DB (even
though there's a bunch of other classes too).

Each package has one or more maintainers, and releases can be
completely independent from other packages or PHP itself.  However, in
future PHP releases we will bundle stable releases of some packages
(PEAR and PEAR_Installer as the very minimum).  This way we get more
control of the quality (and quantity :-) of what is distributed with
PHP.

2. Suggested packages

I suggest that we split the current files in php4/pear into these
packages:

DB
Benchmark
CMD
Cache
Crypt
Date
File_Find
File_SearchReplace
File_Passwd
HTML_IT[X]
HTML_Form
HTML_Menu
HTML_Processor
HTTP
HTTP_Compress
Image_Remote
Log
Mail
Math
PEAR
PHPDoc
Payment
Shedule
XML_RPC
XML_Parser
XML_Render

I've grouped them after how I assume they would be best maintained.
The people who will maintain each package should of course make the
final decision on what packages we should split into and what
files/classes go into each.

Each of these packages gets its own subdirectory in the "pear" CVS
module.

3. CVS tagging standard

When a release is done, the package should be tagged so it is possible
to go back and check out the source as of a specific release later.
The tags could be named "REL_n_n_n" (REL for release, n_n_n is the
release/version number with all non-alphanumeric characters replaced
by an underscore).

4. Code staging (dealing with experimental code etc.)

We need to be able to register some additional information about each
package.  We could use the website/database for this.  One of the
attributes we can register is how mature the code (or a given release)
is, and I think that could replace today's "Experimental".

If a package needs to fork off an experimental development cycle, I
think CVS branches are the best thing to use, with sufficient user
education. :-)

If we decide that CVS branches are too difficult, awkward or whatever,
it could perhaps be done on the filesystem level instead, using a
subdirectory instead of a branch.

 - Stig

-- 
  Stig Sæther Bakken <[email protected]>
  Fast Search & Transfer ASA, Trondheim, Norway