commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject cvs commit: jakarta-commons/latka/doc release-plan-1.0.xml
Date Mon, 25 Mar 2002 00:46:49 GMT
dion        02/03/24 16:46:49

  Added:       latka/doc release-plan-1.0.xml
  Initial Draft
  Revision  Changes    Path
  1.1                  jakarta-commons/latka/doc/release-plan-1.0.xml
  Index: release-plan-1.0.xml
  <?xml version="1.0"?>
  <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
       Author:     dIon Gillard
      Version:    $Id: release-plan-1.0.xml,v 1.1 2002/03/25 00:46:49 dion Exp $
  <chapter id="status">
      <title>Release Plan for Latka 1.0</title>
          <para>This document describes a plan for a 1.0 release of the
  Jakarta-Commons Latka component (for the remainder of this document, simply 
          <para>Per the <ulink url="">
  Jakarta/ASF guidelines</ulink>, 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.</para>
          <para>Non-binding votes (votes cast by those outside the relevant
  committer community) are welcome, but only binding votes are significant for
  decision making purposes.</para>
          <para>The objective of the 1.0 release of Latka is to provide a stable
  and robust release focused on design clarity, forward compatibility, and ease
  of use (i.e., with the intention of providing a stable foundation for the 
  further evolution of the Latka component).</para>
          <para>Specifically, the 1.0 release seeks to
  introduce and evaluate changes based upon the following
  (ordered) criteria:
                  <listitem><para>Freedom from defects (deviation from the 
  documented or reasonably expected behavior)</para></listitem>
                  <listitem><para>Interface and design consistency and clarity,

  ease-of-use, and ease-of-extension.</para></listitem>
                  <listitem><para>Forward compatibility. That is, the ability
  add support for features that can be reasonably predicted without "breaking" 
  the external (and to a lesser degree, internal) interface of the component
          <para>The 1.0 release should also include:
                  <listitem><para>Adequate documentation (including both 
  API-level/JavaDoc documentation as well documentation suitable for use on the 
  Jakarta-Commons site)</para></listitem>
                  <listitem><para>A substantial unit and functional test suite

  suitable for ensuring the quality and compatibility of release 1.0 and 
  subsequent releases.</para></listitem>
                  <listitem><para>A clear demarcation of the "internal" and 
  "external" interfaces within Latka, as defined in the 
  <ulink url="">
  Versioning Guidelines</ulink> document</para></listitem>
          <title>Release Manager</title>
          <para><ulink url="">dIon Gillard</ulink>
  (assuming no one else is really itching to do it)</para>
          <para>(All days ending at 23:59:59 GMT in case of dispute.)
                      <para>Review Period</para>
                      <para>Friday, March 29 - Friday, 5 April 2002</para>
                      <para>During the Review Period specific design, functional and
  contract changes to Latka will be considered on the Jakarta-Commons mailing
  list, using the following process:
                              <listitem><para>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 <ulink url="">
  Jakarta-Commons mailing list</ulink></para></listitem>
                              <listitem><para>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.</para></listitem>
                              <listitem><para>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.
                      <para>The Review Period may be closed before 5 April 2002,
  given one "workday"'s notice and lazy majority approval.</para>
                      <para>The Review Period may be extended by one week (at a 
  time) given lazy majority approval, in case issues still need to be resolved.
                      <para>Implementation Period</para>
                      <para>Friday, 5 April 2002 - Friday, 12 April 2002
  (assuming the Review Period is not extended)</para>
                      <para>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).
                      <para>At the end of the Implementation Period, a formal
  release vote will be called, subject to lazy approval.</para>
                      <para>A formal release vote may be called before 12 April,
  but after the end of the Review Period, if appropriate.</para>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message