This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
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.