I'd like to propose a vote on the following release plan for HTTP Client
1.0. This release plan can also be found at:
http://cvs.apache.org/viewcvs/~checkout~/jakarta-commons/httpclient/RELEASE_PLAN_1_0.txt?content-type=text/plain
Per the Jakarta/ASF guidelines (see
http://jakarta.apache.org/site/decisions.html), this release plan must be
approved via a lazy majority vote. The voting period will end at 23:59:59
GMT on Tuesday 4 September 2001, or when a clear majority has been
established, whichever comes first.
Here's your ballot:
<---- 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 ---->
We still need a volunteer for release manager on this release.
I'll follow up with a proposal on a 2.0 release later today.
- Rod
----
$Id: RELEASE_PLAN_1_0.txt,v 1.1 2001/08/29 15:48:02 rwaldhoff Exp $
Release Plan for HTTP Client 1.0
--------------------------------
Administrivia:
This document describes a plan for the 1.0 release of the
Jakarta-Commons HTTP Client component (for the remainder
of this document, simply "HTTP Client"). 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 1.0 release of HTTP Client is to provide a
stable, relatively bug free release compatible with Jakarta
Slide project and its clients (for the remainder of this
document, simply "Slide").
Any known bugs that can be corrected with minimal
disruption to Slide should be addressed. Any remaining
bugs or deviations from the relevant specifications and
protocols should be noted as "known issues" in the final
release notes.
Release Manager:
??? (Dirk?, Remy?, Scott?)
Timeline: (let's say GMT in case of doubt)
* Wednesday, 5 September 2001
On or before 5 September 2001, all bugs to be addressed
and all features to be added or removed will be
identified. The decision as to whether a bug fix or
feature is deemed "in-scope" for a 1.0 release is to be
determined by a lazy majority vote.
A tentative list includes:
(Note that these are all bugs/issues with the main branch
in Jakarta-Commons. The version in the Slide tree may or
may not have the same set of issues, but we should at
least confirm.)
+ Remove logging changes (rolling back to the stdout
based debugging, or removing logging altogether)
+ Address the "multiple header bug": When two response
headers with the same name are sent, one of them is
ignored. (HTTP/1.0 and HTTP/1.1 say we should treat
"a: one" and "a: two" and "a: one, two".)
+ Address the following HTTP redirect bugs:
+ Query string changes are silently ignored during
redirect.
+ Host/port changes are silently ignored during
redirect.
+ Protocol changes are silently ignored during
redirect
+ Address the following HTTPS related bugs
(alternatively, remove support for HTTPS altogether):
+ Redirects fail for all HTTPS requests
+ When connecting via a proxy, HTTPS parameter is
silently ignored (i.e., we speak HTTP to the proxy
and from the proxy to the destination server)
+ Address the following cookie related bugs
(alternatively, remove support for cookies
altogether):
+ isToBeDiscarded() returns wrong value (false for
true/true for false)
+ Path is ignored when accepting cookies
+ Secure cookies are accepted over insecure
connections
+ Secure cookies are transmitted over insecure
connections
+ When only name/value is supplied, path defaults to
"/". When domain or other parameter is supplied,
path defaults to null.
+ Secure parameter being inapproriately sent in
"cookie" header.
+ Expires attribute doesn't work for some date formats
accepted by commons browsers and sent by common
servers.
+ "Deleting" cookies doesn't fully work--cookies
remain in State (but are not transmitted)
+ When cookies exist but no cookies match the given
request, "Cookie: $Version=1" is submitted, rather
than no Cookie header at all.
+ When not specified, cookie path should default to
(directory containing the) request path, not "/"
+ NameValuePair.equals method throws NullPointerException
when name or value is null
(Assuming this plan is accepted, I'll follow up with a
ballot along these lines.)
* Wednesday, 12 September 2001
(Hopefully) the in-scope changes will be addressed by 12
September 2001, at which time a formal release vote will
be called, subject to lazy majority approval. A formal
release vote may be called before 12 September, if
appropriate.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
