[Esapi-dev] Proposal

[Jim Manico]

Kevin - no slam taken! It's critical that we get this all on the  
table. I think your email below is right on the money. I do not want  
to damper enthusiasm (or do anything rash) but this is a critical - if  
not the most critical converation we should be having, IMO.

And this is not specific to telecom - it's just one way that  
professional software developers release versions of software.

I'm especially impressed with your plans towards GA.

The tough part will be taking what was once deemed production and  
relabeling it as alpha. That's going to require eating a big plate of  
crow for many of us and I'm hitting up the list for thoughts before  
anything rash is done.

And Mike, I like your thoughs as well. The three of us seem to be on  
the same page. I will combine these ideas and set up a proposed plan  
on the wiki soon.

My goals here are (1) to communicate "where we are at" in a way that  
is fair to the ESAPI user community and (2) provide a clear roadmap  
towards a full GA version of ESAPI that truly meets GA criteria.

- Jim

On Jan 15, 2010, at 3:29 AM, "Kevin W. Wall" <kevin.w.wall at gmail.com>  
wrote:

> Jim Manico wrote:
>> I would like to propose that we rethink out version scheme for  
>> ESAPI as
>> follows:
>>
>> 1)  We relabel ESAPI 1.4.1 as ESAPI 1.4.1 ALPHA.
>> 2)  We relabel ESAPI 2.0 rc4 as ESAPI 2.0 rc4 BETA.
>>
>> And even calling EASPI 2.0 BETA is a little reaching - and would  
>> require
>> that we build a clear plan of action before we hit GA status (general
>> availability). Also, calling a release candidate BETA is odd at best,
>> but is needed to support our legacy version scheme.
>
> I don't think that calling a release candidate a BETA is weird at all.
> That's what I've always considered them...something that you needed to
> think twice before using in a production environment. In reality  
> though,
> many RCs are close to ALPHA quality and IMHO, that was the way that at
> least ESAPI 2.0 rc 2 was. (No slam intended!)
>
> I especially like your proposal about having some plan of action  
> before
> calling a release GA. That fits well of how things are done in the  
> telecom
> industry at least and probably other major business sectors as well.
> Generally the way this is done is via a User Acceptance Test (UAT) and
> the user community has significant input as to what those UAT test  
> cases
> are going to be. GA also requires a certain level of documentation
> completeness.  The most important thing is that one needs to define
> this GA criteria so it is independent and well in advance of any and
> all releases. (Oops! ;-)
>
> Unfortunately, I see a downside to your proposal as well. I think that
> there is going to be confusion calling the 1.4 releases 'ALPHA'. In  
> fact,
> had you done that from the beginning, I'm pretty sure that all those
> early adopters would not have used it--at least not in their  
> production,
> mission critical code.
>
> Lastly, I am a bit confused about your statement
>    "even calling EASPI 2.0 BETA is a little reaching"
> Are you referring to while 2.0 is being released as Release  
> Candidates?
> If so, I completely agree. But if you are speaking of the final
> 2.0 release as only being BETA, then I would contend that you simply
> should have done a couple more Release Candidates. Because unless
> you want the ESAPI user community to get really confused, I don't
> think want the official 2.0 release to be referred to BETA. I think
> that definitely needs to be GA.
>
> So that leaves us with defining all the GA criteria. In light of your
> proposal, I will make a starting proposal for that of my own. I think
> that the GA criteria should be:
>
> 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.
>
> -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