Re: [PROPOSAL] 2.1 release plan

[Eric Johnson <er...@tibco.com>]

Oleg,

I have three comments on your proposal, since nobody else seems to have 
given feedback....

1) Some of the headers refer to "2.0", whereas the body of those same 
sections refers to "2.1".  I think you meant to change the headers....

2) For the "post 2.1" development section, I found the intent and 
content of this section confusing.  Is it supposed to be outlining how 
to develop 2.1.X releases, or 2.X releases, or X.X releases, or all of 
the above?  In any case, there seems to be insufficient detail.

3) I'd like to seem some mention and perhaps the inclusion of the 
development of the 3.0 interface suite, if others are actually agreeing 
to what I proposed(?).  If we get the APIs out there, we get feedback on 
them sooner, and can deliver 3.0 sooner.  Therefore I'd like to see them 
have some official mention in a 2.1 release.

Thanks for pulling this together.

-Eric.

Kalnichevski, Oleg wrote:

>All,
>I have taken the liberty of compiling a draft 2.1 release plan that incorporates various ideas tossed around recently (special thanks go to Eric Johnson). I feel we ought to clearly articulate our short- to mid-term development plans before 2.0 goes RC1. 
>
>Comments, ideas, critique welcome 
>
>Cheers
>
>Oleg
>
>
>
>  
>
>------------------------------------------------------------------------
>
>$Id$
>
>Release Plan for HttpClient 2.1
>-----------------------------------------
>
>Administrivia:
>
>This document describes a plan for a 2.1 release of the
>Jakarta-Commons HttpClient component (for the remainder
>of this document, simply "HttpClient").  Per the
>Jakarta/ASF guidelines
>(http://jakarta.apache.org/site/decisions.html), this
>document doesn't mean anything until accepted by the
>relevant committer community via a lazy majority vote
>(hereafter, simply "lazy majority").  Once accepted, it may
>be replaced by an alternative plan, again subject to lazy
>majority approval.
>
>Non-binding votes (votes cast by those outside the relevant
>committer community) are welcome, but only binding votes
>are significant for decision making purposes.
>
>Objective:
>
>The objective of the 2.1 release of HttpClient is to build upon 
>the foundation laid with the previous release while addressing 
>those  architectural shortcomings and flaws identified during 2.0 
>development process. Several well known and much complained about 
>problems could not be resolved without sacrificing API stability. 
>The primary motivation behind the 2.1 is to fix those design 
>limitations, breaking 2.0 API compatibility where absolutely 
>unavoidable, while preserving overall compatibility with 2.0
>use patterns.  
>
>Planned fixes and modifications:
>
> 1. Better exception handling framework (Bug #19868).
>
> 2. Cross-site redirect fix. Authentication, redirect & retry logic
>    to be moved from HttpMethodBase to HttpClient (Bug #20089,
>    #16729).
>
> 3. New configuration architecture that includes plug-in mechanism 
>    for cookie policies & authentication schemes (Bug #15435, 
>    #10790, #10790, #15297, #21151).
>
> 4. More reliable header parser (Bug #11240).
>
> 5. Ability to abort requests (Bug #20288).
>
> 6. A better test framework than SimpleHttpConnectionManager, that 
>    allows to more closely mimic real  HttpConnection behavior, 
>    thus enabling more tests without actually requiring a real 
>    connection. 
>
> 7. Decision on new external dependencies: commons-lang, commons-codec
>    (Bug #16881)
>
> 8. Removal of functions & classes deprecated in 2.0
>
>
>Release Manager:
>
>  Jeff "Jandalf" Dever (Starting July 31, 2002)
>
>
>Voting:
> <---- Please return this portion with your vote ---->
>[ ] +1    I am in favor of this plan and I will help
>[ ] +0    I am in favor of this plan, but I am unable to help
>[ ] -0    I am not in favor of this plan
>[ ] -1    I am opposed to this plan being executed, and my reason is:
> <---- /Please return this portion with your vote ---->
>
> 
>Feature/Fault Tracking:
>
>BugZilla will be the mechanism for tracking features and faults
>(ie: bugs).  When the new Scarab system becomes available, Scarab
>will replace BugZilla in this role.
>
>Milestone development will begin immediately on approval
>of this release plan.  All repository changes that are non-trivial 
>will require a bugzilla bug or feature enhancement request.
>It will be the responsibility of the release manager to categorize
>bugs/features into release versions, but will always remain
>subject to the will of the majority.  In order to declare that a
>release has been reached, all bugs/features categorized into 
>that target release must be completed and a vote must pass 
>subject to lazy approval.
>
>The following procedure will be followed:
>1) All changes must be motivated by a bugzilla change request.
>2) Patches constructed according to standard practice should be 
>attached to the relevant BugZilla bug.
>3) A committer can then commit the patch to the repository.
>
>
>Milestone Development Phases:
>
>2.1 Alpha development
>Designations: 2.1A1, 2.1A2
>During the previous period of development, many new features
>were added, dependencies were changes, interfaces were impacted.
>During Milestone development, the nature of the changes will
>focus on:
>a) interface changes
>b) functionality additions
>c) fault fixing
>
>2.0 Beta development
>Designations: 2.1B1, 2.1B2
>Development will be focused on quality and stability.  No new
>major features will be added, with the following change types
>being the most prelevent:
>a) fix faults with accompanying test cases
>b) additional test cases to improve functionality
>c) improve documentation
>
>2.0 Release development
>Designations: 2.1RC1, 2.1RC2, 2.1
>When all features are complete and all reported bugs have been fixed,
>a release candidate (RC) build will be released.  Any reported bugs
>that are targeted for the 2.1 release will be fixed and a new RC
>build will be released.  After a week of no changes, the last RC
>build will become the 2.1 release with the following changes only:
>release version, aside from:
>a) change the release tag in the build.xml/project.xml
>b) update the site documentation to indicate that there is a release
>
>Post 2.1 Release development
>Designations: 3.0.x
>Following the release, only Bugzilla tracked bugs with attached
>patches will be committed to the repository.  These patches must
>only:
>a) fix faults with accompanying test case(s)
>b) improve documentation
>  
>
>------------------------------------------------------------------------
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>

Re: [PROPOSAL] 2.1 release plan

[Oleg Kalnichevski <ol...@apache.org>]

Hi Eric


> 1) Some of the headers refer to "2.0", whereas the body of those same 
> sections refers to "2.1".  I think you meant to change the headers....
> 

I have to confess that I am guilty of just taking 2.0 release plan as a
template, as I had never written release plans before. Apparently I have
overlooked a few references to 2.0 plan. 


> 2) For the "post 2.1" development section, I found the intent and 
> content of this section confusing.  Is it supposed to be outlining how 
> to develop 2.1.X releases, or 2.X releases, or X.X releases, or all of 
> the above?  In any case, there seems to be insufficient detail.
> 

This entire section is copied from 2.0 release plan pretty much
verbatim. My assumption was that it described standard Apache milestone
development process. I felt I should not monkey around with it too much.
If there is someone who happens to know more about Apache development
process, please advise if we should keep that section in the release
plan. 


> 3) I'd like to seem some mention and perhaps the inclusion of the 
> development of the 3.0 interface suite, if others are actually agreeing 
> to what I proposed(?).  If we get the APIs out there, we get feedback on 
> them sooner, and can deliver 3.0 sooner.  Therefore I'd like to see them 
> have some official mention in a 2.1 release.
> 

I believe 2.1 & 3.0 release plans should be kept as separate documents.
I was planning to start working on release 3.0 plan, which would be
entirely based on the architecture you suggested, as soon as this one is
finalised. 

As you can all see, documentation is not exactly my cup of tee, but I am
trying. If you are interested, you can take the lead in articulating 3.0
development plan. I will happily play a supportive role

Cheers

Oleg