rwaldhoff 01/08/30 14:58:39
Modified: . VERSIONING-GUIDELINES.txt
Log:
minor corrections
Revision Changes Path
1.2 +13 -15 jakarta-commons/VERSIONING-GUIDELINES.txt
Index: VERSIONING-GUIDELINES.txt
===================================================================
RCS file: /home/cvs/jakarta-commons/VERSIONING-GUIDELINES.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- VERSIONING-GUIDELINES.txt 2001/08/30 18:29:37 1.1
+++ VERSIONING-GUIDELINES.txt 2001/08/30 21:58:39 1.2
@@ -1,4 +1,4 @@
-$Id: VERSIONING-GUIDELINES.txt,v 1.1 2001/08/30 18:29:37 rwaldhoff Exp $
+$Id: VERSIONING-GUIDELINES.txt,v 1.2 2001/08/30 21:58:39 rwaldhoff Exp $
-----------------------------------------------------------
This is a draft set of recommendations, adapted from a
similar document in the Jakarta-Taglibs project. It is not
@@ -22,7 +22,6 @@
3.1 "FULLY-COMPATIBLE" CHANGES
3.2 "INTERFACE-COMPATIBLE" CHANGES
3.3 "EXTERNAL-INTERFACE-COMPATIBLE" CHANGES
-3.4 "INCOMPATIBLE" CHANGES
4 RELEASE TYPES
4.1 "MAJOR" RELEASES
@@ -242,7 +241,7 @@
4 RELEASE TYPES
We identify five types of releases: "Major", "Minor",
-"Point", and "Beta".
+"Point", "Beta" and "Milestone".
Developers are encouraged to "upgrade" a release to a
stronger type whenever the nature or scope of the change
@@ -377,10 +376,10 @@
When a component 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
-component state will change from "in development" to
-"beta". The component will remain in this state until
-it is ready for its first major release.
+a "beta" release. At this point, the component state will
+change from "in development" to "beta". The component 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 component is
@@ -389,13 +388,12 @@
6.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 component status
-will be changed from "beta" to "released". In the future
-this component will always be considered to be in the
-"released" state, even when new releases are initiate.
-The only exception is in the case of "unsupported"
-components.
+developers will vote to perform the first major release.
+At this point, the component status will be changed from
+"beta" to "released". In the future this component will
+always be considered to be in the "released" state, even
+when new releases are initiated. The only exception is in
+the case of "unsupported" components.
6.4 "UNSUPPORTED" STATE
@@ -425,5 +423,5 @@
interface of release 2.3.0. Then the maintainers of Bar
can state with a high degree of certainty that Bar will
work with any 2.3.x release of superwidget. Only once 2.4
-(or 3.0) is released, will Bar's developers have to
+(or 3.0) is released will Bar's developers have to
re-evaluate.
