Development snapshot available

[Curt Arnold <ca...@apache.org>]

I've placed a snapshot assembly (equivalent .tar.gz and .zip) at http://people.apache.org/builds/logging/log4php 
.  Knut had mentioned off-list that he was having problems producing  
an assembly, so I put one out there for review.  Over the last two  
days, I think that I have addressed all the policy issues (license  
notices, incubation notices, et al).

For background, you should review:

http://incubator.apache.org/guides/releasemanagement.html
http://incubator.apache.org/guides/branding.html
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases

The release management document briefly describes the different  
approaches to version identification used in various ASF projects.   
The term "Release Candidate" can be used in two significantly  
different meanings, so you need to be clear which meaning is intended:

1. Anything that the ASF releases (that is, anything that is intended  
for use by end-users as opposed to nightly builds, etc) requires a  
vote.  A vote requires some "candidate" to vote to approve or reject  
as a release, so any artifact presented for a vote may be called a  
release candidate even if the intended release is to be designated an  
"alpha" or "beta".  This type of "release candidate" is not intended  
to be distributed to end-users.  If the vote passes the archive file  
name is changed from "apache-foo-1.2.7-RC1.tar.gz" to "apache- 
foo-1.2.7.tar.gz" and the file moved to http://www.apache.org/dist.   
If the vote fails, the "release candidate" is deleted.

2. An indication of the release quality and compatibility guarantees  
higher that "alpha" and "beta".  In this sense, a release candidate is  
intended to be distributed to end-users and has almost the highest  
level of quality and compatibility.

When I use the term release candidate, it is typically in the first  
sense.  If I had to use the second sense, I might call it a gamma.

The alpha and beta designations are used differently in different  
projects.  I believe the httpd project uses "alpha", "beta" and  
"general availability" as mutable descriptions of an immutable release  
identified with a numeric release version.  So httpd 2.2.6 might first  
be a beta and then if not significant issues are found it might become  
general availability.   If there are problems, then httpd 2.2.7 would  
be built and released as a beta.

Other projects will combine a numeric version and an "alpha" or  
"beta", so you'd have log4j 1.3alpha8 as the 8th alpha version leading  
to an eventual intended log4j 1.3 (FYI: log4j 1.3 is abandoned).

Major numbers often imply compatibility guarantees, so the first of a  
new major version may be significant.

With that all in mind, the project will need to agree on a version  
naming strategy before preparing anything for release.  Options I see  
are:

1. Use 1.9.x for releases prior to establishing compatibility promises  
with 2.0.

2. Use 2.0alpha or 2.0beta for releases prior to establishing 2.0.

Building the assembly should be fairly simple (it still needs to be  
refined)

Install Maven 2, PHP 5.x, PHPDocumentor and PHPUnit

Run "mvn site assembly:assembly" which will check all PHP files for  
syntax errors, run PHPUnit tests, generate web site and PHPDocumentor  
generated content and prepare assemblies in the target directory.