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.
