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.