RELEASE_PLAN_1_1.txt

Release Plan for Pool 1.1
--------------------------

Administrivia:

This document describes a plan for a 1.1 release of the
Jakarta-Commons Pool component (for the remainder
of this document, simply "Pool").  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 1.1 release of Pool is to
provide a stable and robust release with the intention of 
providing a stable foundation for the further evolution of 
the Pool component. 

Release Manager:

  Dirk Verbeeck
  (assuming no one else is really itching to do it)

Release Process:

The Jakarta Commons release process will be followed.
http://jakarta.apache.org/commons/releases/index.html

Timeline:
(All days ending at 23:59:59 GMT in case of dispute.)

* Preparation Period
  28 September 2003 - 30 September 2003

  During this period, all issues preventing building a
  release candidate should be a addressed. All other 
  updates (documentation and website) are not blocking.


* Review Period
  1 October 2003 - 15 October 2003

  During the Review Period specific design, functional and
  contract changes to Pool 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.

  The Review Period may be extended by one week (at a time)
  given lazy majority approval, in case issues still need
  to be resolved.

  To facilitate the review process Release Candidates 
  (RC1, RC2, ...) will be provided at the start of the 
  review period and when mayor issues are resolved.

* Implementation Period
  16 October 2003 - 19 October 2003
  (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.

  A formal release vote may be called before 19 October 2003,
  but after the end of the Review Period, if appropriate.
  (As soon as all remaining issues are resolved)

* Release Pool 1.1
  20 October 2003