ESAPI Plan

We need to have a plan of action before calling a release GA (General Availability).

Proposed General Availability Criteria:

1) 100% Unit tests pass.
2) All classes must have unit tests.
3) Test coverage must test 100% of the "sunny day" paths and at least

80% of the total paths. (This will require using some sort of code
coverage during unit testing.)

4) At least 3 independent adoptions of the previous beta RC for the

given release must provide their approval.

5) All public features must be documented in terms of:

a) API documentation (e.g., Javadoc)
b) Document when this feature should be considered / used
c) Example(s) showing how this feature should be used

6) Once all these things are completed, we open it up to a formal

vote by the ESAPI-Users group and then it is only made GA if
they approve. (I would say by at least 60%, but your opinion may
vary.)

If not obvious, the reason for adding # 4 & 6 is that generally UAT is done by individual clients using said software. In this case, unless we can get the unanimous ESAPI community consensus on a UAT (e.g., if the ESAPI-Users wrote up a formal test plan that needed to be tested against) this is probably the best we can do.