You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by js...@apache.org on 2002/08/05 16:06:22 UTC
cvs commit: jakarta-commons/httpclient RELEASE_PLAN_2_0.txt
jsdever 2002/08/05 07:06:22
Modified: httpclient RELEASE_PLAN_2_0.txt
Log:
Release plan available for voting.
Revision Changes Path
1.4 +76 -83 jakarta-commons/httpclient/RELEASE_PLAN_2_0.txt
Index: RELEASE_PLAN_2_0.txt
===================================================================
RCS file: /home/cvs/jakarta-commons/httpclient/RELEASE_PLAN_2_0.txt,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- RELEASE_PLAN_2_0.txt 21 Jul 2002 04:12:44 -0000 1.3
+++ RELEASE_PLAN_2_0.txt 5 Aug 2002 14:06:22 -0000 1.4
@@ -1,7 +1,7 @@
$Id$
-Release Plan for HttpClient 2.0
---------------------------------
+Release Plan for HttpClient 2.0 (revised)
+-----------------------------------------
Administrivia:
@@ -47,10 +47,6 @@
(and to a lesser degree, internal) interface of the
component.
- 5. Functional compatibility with HttpClient 1.0 (i.e.,
- if it works in 1.0 it should work in 2.0)
-
- 6. API Compatibility with HttpClient 1.0.
The 2.0 release should also include:
@@ -67,10 +63,11 @@
VERSIONING_GUIDELINES.txt document at:
http://cvs.apache.org/viewcvs/~checkout~/jakarta-commons/VERSIONING-GUIDELINES.txt
+
Release Manager:
- Rodney Waldhoff
- (assuming no one else is really itching to do it)
+ Jeff Dever (Starting July 31, 2002)
+
Voting:
<---- Please return this portion with your vote ---->
@@ -80,78 +77,74 @@
[ ] -1 I am opposed to this plan being executed, and my reason is:
<---- /Please return this portion with your vote ---->
-Timeline:
-(All days ending at 23:59:59 GMT in case of dispute.)
-(The term "bug" is used equivelently with "enhancement")
-
-* Add and Vote on bugs in Bugzilla
- Friday, July 12, 2002 - Friday, July 19 2002
-
- A large number of enhancements have been proposed over the
- months on the mailing list. These have been accumulated
- and added to bugzilla. These bugs and enhancements will
- have to be mapped into release milestones towards a pending
- 2.0 release.
-
- During this period, everyone is encouraged to review the bugs
- and add their votes and comments directly into bugzilla.
- The votes and comments will be used to help determine which
- the priority level, severity and milestone in which the bug
- must be completed.
-
-*
- During the Review Period specific design, functional and
- contract changes to HttpClient will be considered on the
- Jakarta-Commons mailing list, using the following
- process:
-
- 1) Any developer or committer that would like to see
- a specific change (or group of changes) enacted or
- rolled back will suggest it on the Jakarta-Commons
- mailing list (jakarta-commons@jakarta.apache.org).
-
- 2) Any interested committer that opposes a given change
- (or group of changes) is obligated to indicate this
- disapproval on the list during the Review Period.
-
- 3) We will seek, but not strictly require consensus on
- each decision point. If consensus cannot be reached,
- any committer may call for a vote to resolve the
- issue via a lazy majority vote.
-
- Since substantial progress has been made on a number of
- the objectives within the "rlwrefactoring" branch of HTTP
- Client within the CVS tree, it is suggested that we use
- that revision as a starting point. Of course, no changes
- within that branch are set in stone. (Indeed, even the
- author of those changes has several things he'd still
- like to reconsider.) One summary of the major changes
- in this branch versus the current main branch of HTTP
- Client can be found at:
-
- http://www.mail-archive.com/jakarta-commons@jakarta.apache.org/msg03954.html
-
- The Review Period may be closed before 13 September 2001,
- given one "workday"'s notice and lazy majority approval.
-
- The Review Period may be extended by one week (at a time)
- given lazy majority approval, in case issues still need
- to be resolved.
-
-* Implementation Period
- Friday, 14 September 2001 - Monday, 24 September 2001
- (assuming the Review Period is not extended)
-
- During this period, any remaining implementation, testing
- and documentation will be completed. No new features
- or "public" interface changes will be considered
- in-scope at this time (short of a lazy-majority
- approved revised release plan or any "showstopper"
- defects).
-
- At the end of the Implementation Period, a formal
- release vote will be called, subject to lazy
- approval.
+
+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.
+
+The previous 2.0 release plan called for a time ordered development
+strategy. There were set dates for given phases of the implementation.
+This approach will be abandoned in favour of a milestone based
+development plan.
+
+Milestone development will begin immeadiately 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 milestones, but will always remain
+subject to the will of the majority. In order to declare that a
+milestone has been reached, all bugs/features categorized into
+that target milestone 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 relevent BugZilla bug.
+3) A committer can then commit the patch to the repository.
+
+
+Milestone Development Phases:
+
+2.0 Milestone development
+Desinations: 2.0M1, 2.0M2
+During the previous period of development, many new features
+were added, depenancies 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
+Desinations: 2.0B1, 2.0B2
+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 accompayning test cases
+b) additional test cases to improve functionality
+c) improve documentation
+
+2.0 Release development
+Desintation: 2.0RC1, 2.0RC2, 2.0
+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.0 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.0 release with the following changes only:
+release version, aside from:
+a) change the release tag in the build.xml/maven.xml
+b) update the site documentation to indicate that there is a release
+
+Post 2.0 Release development
+Desintations: 2.0.x
+Following the release, only Bugzilla tracked bugs with attached
+patches will be commited to the repository. These patches must
+only:
+a) fix faults with accompanying test case(s)
+b) improve documentation
+
+
- A formal release vote may be called before 24 September,
- but after the end of the Review Period, if appropriate.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>