Differences between revisions 7 and 8
Revision 7 as of 2005-08-18 22:03:52
Size: 3474
Editor: lc-ez-63-96-185-209
Comment: this is the first cut of release criteria for Beehive v1
Revision 8 as of 2005-08-18 23:13:22
Size: 3341
Editor: lc-ez-63-96-185-28
Comment: Tweaks to the release criteria.
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
''Author: Steve Tocco Last Revised Date: 5/18/05, Version 1.0'' ''Last Revised Date: 8/18/2005''
Line 4: Line 4:
This document outlines all of the release criteria to be satisfied so Beehive 1.0 can be released.   This document outlines all of the release criteria to be satisfied voting on Beehive 1.0 release.
Line 6: Line 6:
In the remainder of this document, the Subversion revision number that
(eventually) reflects Beehive 1.0 will be simply referred to as the '''release candidate'''.
In the remainder of this document, the Subversion revision number that (eventually) reflects Beehive 1.0 will be simply referred to as the '''release candidate'''.
Line 14: Line 13:
||1.0||All DRTs/Checkin tests pass at 100% when executed against the release candidate revision number in the source tree.||All DRTs must pass at 100% for NetUI, and Controls. JWS is not required.|| ||1.0||All DRTs tests pass at 100% when executed against the release candidate revision number in the source tree.||All DRTs must pass at 100% for NetUI, and Controls. JWS is not required.||
Line 17: Line 16:
||1.3||The javadoc target for the release candidate must be able to pass successfully.||We must be able to successfully build the javadoc.|| ||1.3||The JavaDoc target for the release candidate must be able to pass successfully.||We must be able to successfully build the javadoc.||
Line 22: Line 21:
||2.2||All tests (DRTs/checkin/BVTs/detailed) in support of Beehive must be able to be executed from the test distribution against the distribution derived from the release candidate.||Thus test code must fully be enabled to run in this manner.||
||2.3||The distribution created from the release candidate must be published for download and signed.|| ||
||2.2||All tests (DRTs/BVTs) in support of Beehive must be able to be executed from the test distribution against the distribution derived from the release candidate.||Thus test code must fully be enabled to run in this manner.||
Line 25: Line 23:
||3.0||A list of known issues must be produced and published in support of the release candidate. This should capture all known defects (from JIRA) the user may encounter. This need not include enhancements and documentation bugs.||Could be published as part of the dist itself or perhaps on the Beehive website.   If part of the dist, must be made before the vote.||
||3.1||For the release candidate, no open bugs will exist. All items will be fixed or assigned to the new release.||Currently all things for the future are assigned to Fix For version equal to “TBD”.||
||3.2||For the release candidate, no resolved bugs will exist. All items will be fixed or assigned to the new release.||There are some exceptions for this for code that is not shipping such as WSM and src tree only infrastructure.||
||3.0||A list of known issues must be produced and published in support of the release candidate. This should capture all known defects (from JIRA) the user may encounter. This need not include enhancements and infrastructure / documentation bugs.||Could be published as part of the dist itself or perhaps on the Beehive website. If part of the dist, must be made before the vote.||
||3.1||For the release candidate, no open bugs will exist. All items will be fixed or assigned to the new release.||Currently all things for the future are assigned to "Fix For" version equal to “TBD”.||
||3.2||For the release candidate, no resolved bugs will exist assigned to the "V1" version; all items will be fixed or assigned to the next release.||There are some exceptions for this for code that is not shipping with V1 and SVN-only infrastructure.||
Line 29: Line 27:
||4.0||All Java Doc for “Public Use” APIs must be authored as part of the release candidate.||This is mainly a driver to indicate if there is any API that we intend users to implement/understand, Javadoc must be provided.|| ||4.0||All JavaDoc for “Public Use” APIs must be authored as part of the release candidate.||This is mainly a driver to indicate if there is any API that we intend users to implement/understand, JavaDoc must be provided.||

BEEHIVE 1.0 RELEASE CRITERIA Last Revised Date: 8/18/2005

This document outlines all of the release criteria to be satisfied voting on Beehive 1.0 release.

In the remainder of this document, the Subversion revision number that (eventually) reflects Beehive 1.0 will be simply referred to as the release candidate.

The release criteria generally fall into one of the following areas: Source Tree, Distribution Bits, Release Planning, and Documentation.

SOURCE TREE

Number

Objective

Background

1.0

All DRTs tests pass at 100% when executed against the release candidate revision number in the source tree.

All DRTs must pass at 100% for NetUI, and Controls. JWS is not required.

1.1

All BVT tests pass at 100% when executed against the release candidate revision number in the source tree.

Any BVTs not passing should have JIRA issue filed and be commented out for the release candidate. If at a later date a fix is to be added to 1.0 (something like 1.0.1) the test can be re-enabled in the 1.0 branch or in the next major release (1.1 or 2.0). JWS is not required.

1.2

Any tests commented out due to failures should have JIRA issues filed (defects or enhancements) to be fixed in subsequent releases. Comments within test configuration files should indicate the JIRA issue tracking the problem.

1.3

The JavaDoc target for the release candidate must be able to pass successfully.

We must be able to successfully build the javadoc.

1.4

JSF integration tests must pass at 100%.

Not part of normal BVT target.

DISTRIBUTION BITS

2.0

The Beehive Distribution must be able to be created from the release candidate.

We must be able to build the distribution from the release candidate.

2.1

The Beehive Test Distribution must be able to be created from the release candidate.

We must be able to build the test distribution from the release candidate.

2.2

All tests (DRTs/BVTs) in support of Beehive must be able to be executed from the test distribution against the distribution derived from the release candidate.

Thus test code must fully be enabled to run in this manner.

RELEASE PLANNING

3.0

A list of known issues must be produced and published in support of the release candidate. This should capture all known defects (from JIRA) the user may encounter. This need not include enhancements and infrastructure / documentation bugs.

Could be published as part of the dist itself or perhaps on the Beehive website. If part of the dist, must be made before the vote.

3.1

For the release candidate, no open bugs will exist. All items will be fixed or assigned to the new release.

Currently all things for the future are assigned to "Fix For" version equal to “TBD”.

3.2

For the release candidate, no resolved bugs will exist assigned to the "V1" version; all items will be fixed or assigned to the next release.

There are some exceptions for this for code that is not shipping with V1 and SVN-only infrastructure.

DOCUMENTATION

4.0

All JavaDoc for “Public Use” APIs must be authored as part of the release candidate.

This is mainly a driver to indicate if there is any API that we intend users to implement/understand, JavaDoc must be provided.

V1ReleaseCriteria (last edited 2009-09-20 23:24:30 by localhost)