Status: This project page is a collection of general information, not related to a special project of mine.
This page describes my standard way of creating software releases. For small projects, things might be handled different, because there is some amount of administrative overhead caused by this procedure. However, for larger coding projects, this document serves as a reference for me.
Contents
Versioning
Version numbers
Version numbers have the format "M.N[.B]", with major release number M, minor release number N, and an optional beta- or subrelease number B. Counting of M starts at 1 for the first stable release, counting of N and B starts at 0 for each new M and N, respectively. A new number is created by incrementing the current number by one (1).
If a release is to be created during initial project development before the first production release is considered ready, a major release number M=0 is used.
If in a project a version number is required for coding purposes before the first release has been created, and no version number has yet been assigned, version number 0.0 is to be used.
Beta versions are created after feature freeze, see the Release cycle section below for details.
Build IDs
If during development and sustaining checkpoints in CVS are to be created for change management or bug tracking purposes, build IDs are assigned. These are tagged in CVS as BUILD_N, where N is an integer, starting at 1 (one), and being incremented by one (1) for subsequent build IDs.
Bug tracking
This section describes bug tracking and general change management process through thiemo.net Bugtraq (using the open source Mantis bug tracking tool with some adjustments, mainly to status and resolution texts).
Bug Submission
When a bug is reported using thiemo.net Bugtraq, it is assigned a unique bug ID number, and placed in status NEW, by the Bugtraq system.
Initial evaluation
Development then reviews the bug report and verifies its validity, checking for clear description of a problem described or a feature requested, in English language. If formal and content requirements are met, and the bug is found to be ready for technical inspection,
- Status is set to ACCEPTED
- Projection is set as required
- Target version is set as required
- Priority is set as required
- Severity is set as required
- View status is checked and adjusted, if required
- Requested-by is set to contain the name of the reporter, or "Development" (the default setting)
If the bug report is sensible, but information required for working on it is found to be missing, the missing information is requested from the reporter (either by using Bugtraq or by external mail), and
- Status is set to NEED INFO
If the bug report is found to be invalid, and the cause is more than a lack of information details,
- Fixed in Version is set to the next version
- Resolution is set to INVALID
- Status is set to CLOSED
If the bug report is found to be not fixable for other reasons,
- Fixed in Version is set to the next version
- Resolution is set as required
- Status is set to CLOSED
Bug fixing
When work on the bug report is started, before any other activity,
- Status is set to WORK IN PROGRESS
- ETA is set as required
- Assigned To is checked and adjusted, if required
Fix verification
When work is done, and the fix is considered ready,
- Status is set to FIX VERIFICATION
- Resolution is set to FIXED
- Fixed in Version is set to the next version that will contain the complete fix for the bug
- Fixed-in-Build is set to the lowest build number that contains the complete fix if build numbering is used in the project
Fixed successfully
If, by testing or other means, it is reasonable to assume the fix implemented indeed fixes the bug,
- Status is set to ISSUE SOLVED
Fix failed
If by testing, after a bug has been placed in FIX VERIFICATION, it is found that the bug is not resolved,
- Resolution is set to REOPENED
- Status is set to WORK IN PROGRESS
Next process step will be "Fix verification" described above.
Release cycle
This section describes the steps to take for generation of a "release" version of software, which is considered a stable point in development.
T-21: Feature freeze
Three weeks before a planned release date, the code enters the "feature freeze" state. This means that no new features will be implemented from this time on, only bugfixes are allowed.
Implementation of features that has already started may continue if (and only if) it would break existing functionality if left unimplemented.
Documentation changes that refer to existing functionality changes shall be finished in this state.
The RELENG_X_Y CVS branch is created from HEAD at T-21:
> cvs update -A > cvs tag -b RELENG_X_Y
If BUILD_NNN tags were created in the development cycle, they are now deleted (by cvs tag -d BUILD_NNN).
If code changes shall be done in the RELENG branch, it can be checked out or updated with cvs option -r RELENG_X_Y.
Bug fixing in this (and the following) state is to be done in RELENG, and merged to HEAD:
> cvs update -r RELENG_X_Y > cvs tag RELENG_X_Y_BNNN > cvs update -A > cvs update -j RELENG_X_Y_BNNN > cvs commit
T-14: Code freeze, showstoppers only
Two weeks before the planned release date, bugfixing shall be finished on all known functionality flaws. Only bugs that are considered a showstopper, that is, which are preventing the project from being used in the intended way, shall be fixed after this date.
Code changes for this are to be done in RELENG, and merged to HEAD as shown above.
T-7: Code freeze, Go/No-go
One week before the planned release date, all code change activity shall be finished. If there are showstopper issues left to fix, the release date must be deferred according to estimated time to fix.
The week after the Go/No-go decision is used as "soak time", to see if indeed all known issues are fixed for the release.
T-0: Release date
On the planned release date, the release tag is set in CVS on the RELENG branch:
> cvs update -r RELENG_X_Y > cvs tag RELEASE_X_Y
The RELENG beta tags, if any have been created, are deleted in CVS:
> cvs tag -d RELENG_X_Y_BNNN
In Bugtraq, bugs that are solved with this release are set to state "Closed", the release is marked as "Released", and, if not yet done, a release entry is created for the next release.
Development on the RELENG branch will cease with the setting of the release tag. The next release cycle will create a new RELENG branch from HEAD.
Development branches
If development of a future major release shall take place while but not influence the current one, a separate CVS branch named DEVEL_X_Y is created, and this future major release is developed there. Y will usually be 0 in this case. When the release cycle for this new major release shall be entered, code merge into HEAD is neccessary before entering the release cycle, as releases shall always be created from HEAD.
References
THIS DATA IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DATA, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
All product and brand names mentioned on there pages and in the source code are registered names and/or trademarks of the respective owner and are mentioned for identification purposes only.
For a full copyright notice, please see this link. For imprint and contact information, please see http://www.thiemo.net/.