jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From morg...@apache.org
Subject cvs commit: jakarta-taglibs HOWTO-RELEASE
Date Mon, 16 Apr 2001 23:58:31 GMT
morgand     01/04/16 16:58:31

  Modified:    .        HOWTO-RELEASE
  Log:
  reorginized some, and added information on tag library "states"
  
  Revision  Changes    Path
  1.4       +64 -16    jakarta-taglibs/HOWTO-RELEASE
  
  Index: HOWTO-RELEASE
  ===================================================================
  RCS file: /home/cvs/jakarta-taglibs/HOWTO-RELEASE,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- HOWTO-RELEASE	2001/04/16 15:37:25	1.3
  +++ HOWTO-RELEASE	2001/04/16 23:58:31	1.4
  @@ -1,35 +1,61 @@
   HOWTO-RELEASE
   -------------
   
  -1 RELEASES
  +1 RELEASE TYPES
   
  -1.1 RELEASE NUMBERS
  +There are four types of releases: "Major", "Minor", "Bug Fix", and "Beta".  See also Section
2, which describes how releases are numbered.
   
  -1.1.1 INITIAL RELEASE
  +1.1 "MAJOR" RELEASE
   
  -Initial releases are generally released as 1.0, unless there have been versioned beta releases.
  +Major releases signify signifant changes to a tag library.  Developers _may_ perform a
major release if there have been substantial improvements to the tag library.  Developers
_must_ perform a major release if there is _any_ non-backwards compatible change to a tag
interface.
   
  -1.1.2 "MAJOR" RELEASES
  +1.2 "MINOR" RELEASE
   
  -Major releases are denoted by incrementing the first portion of the release number.  For
example, if the current release version is 2.0.4, then the next major release would become
3.0.  The developers _may_ perform a major release if there have been substantial improvements
to the tag library.  The developers _must_ perform a major release if there is _any_ non-backwards
compatible change to a tag interface.
  +Minor releases signify enhancements to a tag library that do not necessitate a major release.
 If the developers change the tag library interfaces in a non-backwards compatible way, those
changes _cannot_ be bundled in a minor release; a major release _must be performed_.  
   
  -1.1.3 "MINOR" RELEASES
  +1.3 "BUG FIX" RELEASES
   
  -Minor releases are denoted by incrementing the second portion of the release number.  For
example, if the current release version is 2.0.4, then the next minor release would become
2.1.  A minor release involves new features or improvements to a tag library that do not necessitate
a major release.  However a major release is _required_ if the developers change the tag library
interfaces in a non-backwards compatible way.
  +A bug fix release involves simple bug fixes that do not introduce new features.  Developers
are not required to perform bug fix releases if they can address the bug in a minor release.
   
  -1.1.4 BUG FIX RELEASES
  +Developers are _strongly encouraged_ but not required to perform bug fix releases on previous
major releases if a bug in that release is uncovered.
   
  -Bug fix releases are denoted by incrementing the third portion of the release number. 
For example, if the current release version is 2.0.4, then the next bug fix release would
be 2.0.5.  A bug fix release involves simple bug fixes that do not introduce new features.
 Developers are not required to perform bug fix releases if they can address the bug in a
minor release.  
  +1.4 "BETA" RELEASES
   
  -Developers are _strongly encouraged_ but not required to perform bug fix releases on previous
major releases if a bug in that release is uncovered.
  +Developers may, at their option, perform a beta preview of any major, minor or bug fix
release.  Beta releases may be performed for a variety of purposes such as:
  +
  +  * Showcasing new, untested features
  +  * Providing early corrections of critical bugs
  +  * Generating a stable version before large-scale changes
  +
  +Developers should attempt to describe the purpose behind the beta release in the "News"
section of the site (see section 5 for details).  While every effort should be made to ensure
the quality of released code, "beta" releases are essentially provided AS-IS with no guarantees
of stability or maintenance.
  +
  +2 RELEASE NUMBERS
  +
  +2.1 INITIAL RELEASE NUMBER
  +
  +A tag library's initial release number is generally 1.0, unless there have been versioned
beta releases.
  +
  +2.2 DISCECTING THE RELEASE NUMBER
  +
  +A release number is comprised of 2-3 components: the major release number, the minor release
number, and an optional bug fix release number.  Here is a sample release number:
  +
  +  2.0.4
  +  
  +and it can be broken into three parts:
  +
  +  major release #   = 2 
  +  minor release #   = 0
  +  bug fix release # = 4
  +
  +The next release of this tag library would increment the appropriate part of the release
number, depending on the type of release (major, minor, or bug fix).  For example, a subsequent
minor release would be version 2.1, or a subsequent major release would be 3.0.
   
  -1.1.5 BETA RELEASES
  +2.5 "BETA" RELEASE NUMBERS
   
  -Developers may, at their option, perform a beta preview of any major, minor or bug fix
release by appending the phrase "beta" to the released jar.  For example, if the current release
version is 2.0.4, and the developer wished to preview the next major release, the jar would
be named foo-3.0-beta.jar.
  +Beta releases are denoted by adding the phrase "beta" after the release number in the released
archive.  For example, if the current release version is 2.0.4, and the developer wished to
preview the next major release, the jar would be named foo-3.0-beta.jar.
   
  -1.2 STARTING/COMPLETING MAJOR RELEASES
  +3 STARTING/COMPLETING MAJOR RELEASES
   
  -Let's assume that the current release of your tag library is 2.0.4, but you want to start
work on 3.0.  Here are the steps you would take to start working on the new release:
  +(See section 1.1 for the definition of a "Major" release.)  Let's assume that the current
release of your tag library is 2.0.4, but you want to start work on 3.0.  Here are the steps
you would take to start working on the new release:
   
     1) Make an announcement on taglibs-dev
     2) Create a branch called rel2 in CVS for the entire tag library,
  @@ -42,7 +68,29 @@
     2) After receiving approval, build the release jar and place it on the site
   
   The version 3 release is the main trunk of the CVS tree.  However, versions 2 and 1 will
still be available on other branches (rel2 and rel1), if other releases of that version prove
necessary.
  +
  +4 DEVELOPMENT STATE
  +
  +Each tag library also has its development state listed on the main website.  There are
four possible states: "in development", "beta", "released", and "unsupported".
  +
  +4.1 "IN DEVELOPMENT" STATE
  +
  +When a tag library is "in development", it is new and still relatively unstable.  Typically
tag libraries in this state do not have any binary releases available beyond the nightly builds.
 Users should be made aware that this tag library may change its functionality before a stable
release is achieved.
  +
  +4.2 "BETA" STATE
  +
  +When a tag library has made significant progress toward release-quality code, the committers
may vote to perform a "beta" release (see section 1.4).  At this point, the tag libraries
state will change from "in development" to "beta".  The tag library will remain in this state
until it is ready for its first major release.
  +
  +Note that developers may skip vote to skip the "beta" state and go directly to "released",
if the tag library is sufficiently stable.
  +
  +4.3 "RELEASED" STATE
  +
  +When a new tag library is finally production-quality, the developers will vote to perform
the first major release (see section 1.1).  At this point, the tag libraries status will be
changed from "beta" to "released".  In the future this tag library will always be considered
to be in the "released" state, even when new releases are begun (section 3).  The only exception
is in the case of "unsupported" tags.
  +
  +4.4 "UNSUPPORTED" STATE
  +
  +Under rare circumstances, the Taglibs committers may vote to make a tag library "unsupported",
if there are no resources to maintain the library or if it has been completely supplanted
by a superior tag library.  Only "released" tags may become "unsupported"; tags in other states
will simply be terminated after a brief warning period.
   
  -2 NEWS
  +5 NEWS
   
   There will be a "news" section of the Jakarta taglibs site.  This portion of the site will
provide a notification of each major, minor or bug fix release of each tag library.  Each
release notification will link to the "news" section for that tag library, which will contain
the details of what new features were introduced, which bugs were fixed, etc.
  
  
  

Mime
View raw message