commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject cvs commit: jakarta-commons/httpclient RELEASE_PLAN_2_0.txt
Date Mon, 05 Aug 2002 14:06:22 GMT
jsdever     2002/08/05 07:06:22

  Modified:    httpclient RELEASE_PLAN_2_0.txt
  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 @@
  -Release Plan for HttpClient 2.0
  +Release Plan for HttpClient 2.0 (revised)
  @@ -47,10 +47,6 @@
       (and to a lesser degree, internal) interface of the
  - 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:
   Release Manager:
  -  Rodney Waldhoff
  -  (assuming no one else is really itching to do it)
  +  Jeff Dever (Starting July 31, 2002)
    <---- 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 ---->
  -(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 (
  -   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:
  -  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
  +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:   <>
For additional commands, e-mail: <>

View raw message