Release Plan for Launcher 1.0

Administrivia

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

Release Manager

  • Dirk Verbeeck

Release Process

The Apache Commons release process will be followed.

Timeline:

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

  • Preparation Period: 11 March 2004 - 27 July 2004
    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: 27 July 2004 - 16 August 2004
    During the Review Period specific design, functional and contract changes to Launcher 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 August 2004 - 20 August 2004
    (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 the end of the implementation period, but after the end of the Review Period, if appropriate. (As soon as all remaining issues are resolved)

  • Release: 20 August 2004