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.