[Esapi-dev] Proposal

[Kevin W. Wall]

Chris Schmidt wrote:
> I agree with you here. I am in a similar situation (discounting the waiting
> for legal) with finally getting the buy-in from the company to integrate
> ESAPI into our codebase. Had it carried with it a BETA label it definately
> would have made it far more difficult, if not impossible, to get the buy in
> from management.
> 
> 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)
> 
> Thoughts?

+1 for that idea as long as we don't throw ALL the other GA criteria out the
window because of it.

OpenSSL has been 0.9.x as long as I can remember and most of us--knowingly or
not--have been using it forever.

-kevin
-- 
Kevin W. Wall
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME