Revision as of 03:22, 17 January 2010

GA (General Availability) Planning

• 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:
   1. API documentation (e.g., Javadoc)
   2. Document when this feature should be considered / used
   3. 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.

• Other Suggestions (Mike B):

This is in my mind further rationale for perhaps even stopping with new features and starting backfilling documentation and tests if needed. I urge people to examine the ESAPI for PHP adapter that one can download from its Google Code repository, and to read the ESAPI design patterns doc, and to re-read Jeff's recent email with some hints about rolling out controls in phases etc., and to dig a little bit in the ESAPI book draft there are a small number of "nuggets" along these lines, in e.g. the user/auth sections for this kind of higher-level guidance e.g. step one map current wrappers to ESAPI interfaces, then start extending user, then ... Anecdotally for example I can report that taking the extended factory pattern adapter route, and building it out in a phased approach, where I as the security guy own the wrapper code, and then the development team uses it according to a cookbook that I write and maintain for them, COMPLETELY puts the security guy in control in terms of determining the quality of the ESAPI security control that's about to be rolled out. I write a new wrapper function for something, and then I add 6-12 proper security function tests (i.e. a few expected successes, then a whole bunch of expected failures) for each with test data that is customer-specific. If ESAPI's broken or not quite there yet, I don't put the wrapper function into the adapter until it's right.

• Other Suggestions (Ed S):

Open source projects need to "Release Early, Release Often" (http://catb.org/esr/writings/homesteading/cathedral-bazaar/ar01s04.html). If we wait until it's perfect it will never happen (I have plenty of code rotting on my disk to prove this).

• Other Suggestions (Beef):

I think that where we are right now is acceptable, and if anything, taking it back to a pre 1.0 release level would have the same basic effect without the negative stigma that goes along with labeling software as "beta" quality.

My alternate proposal would be to prefix the current ESAPI version with a 0.

So esapi 0.1.4.2 and esapi 0.2.0 respectively.

This allows us the luxery of time before a full 1.0 GA release of the API and carries a positive stigma with the development world. Plenty of libraries are in use and have been in use for years before they ever get to a 1.0 release. Had those same libraries been labeled beta, I highly doubt they would have gotten the adoption and implementation rates that they did (an example would be just about an utility that has ever been released for *nix)