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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
