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.
