Release Categories & Nomenclature:
|
Release Categories: A software product consists of one or several software modules within a product name. Changes will be made on different levels, using various release categories. The release categories are: | ||
|
Nomenclature: |
Details |
Considerations |
|
Version = implemented in case of Redesign, New architecture or New functionality. Usually supersedes all preceding minor upgrades, releases and emergency fixes. All appropriate RM documentation required (including Business Requirements, Test documentation, detailed Implementation & Back-out plan, Support Guide, Release Notes, Service Level Agreements, UAT Sign-off, Business Communication & Training Materials. Nomenclature: 1.0.0.0 |
Initial SW Release (Business & infrastructure Apps) Major SW Upgrades Operating System upgrades Major Desktop upgrades New HW builds |
How, When, Where, and by Whom is the version determined? What prevents the use of a lower level release to avoid “Version” level release requirements? How is version audited? How can we make this simple for everyone to understand? Can we use super/sub setting? |
|
Release = Minor features or significant fixes have been added. Implemented in case of improvements of the product’s feature set and/or the addition of new modules. Should include all appropriate RM documentation updates. Nomenclature:1.1.0.0 |
Deployment of latest SW release updates Deployment of new SW modules Deployment of new functionality/features Modifications to HW/Infrastructure Components Software/image upgrades Functionality Moves |
How, When, Where, and by Whom is the release determined? What prevents the use of a lower level release to avoid “Release” level release requirements? How is release audited? |
|
Level = implemented as a group of consolidated vendor Bug Fixes or minor enhancements (MF). Release contains the corrections to a small number of known problems. These do not replace software but rather adjust the existing version until a more permanent upgraded release is available. Documentation should include Requirements, Release Notes, Build procedures, Build notes, Test Documentation, IM/PM reference numbers, detailed deployment instructions, relevant communication, and updates to all other existing related documentation. CMDB/KEDB should be updated to reflect change. The revision number is incremented when minor bugs are fixed. Nomenclature: 1.0.1.0 |
Minor enhancements (including Customer Requests) System Rule Changes Defect Fixes Service Pack deployments Point Releases |
How, When, Where, and by Whom is the level determined? What prevents the use of a lower level release to avoid “Level” level release requirements? How is level audited? |
|
Patch = Customer specific bug fix which is limited to the addition/modification of custom requirements. Documentation should include Release Notes, Deployment instructions, and test information. A fourth number which includes the software build number. Nomenclature: 1.0.0.1 |
System patches (including Security Patches) Bug fixes Firmware upgrades Data Field Fixes All DLL installations and updates Modification of config files Server application client/agent/driver deployments |
How, When, Where, and by Whom is the patch determined? What prevents the use of a lower level release to avoid “Patch” level release requirements? How is patch audited? |
|
Urgent/Emergency Release = A Release is required immediately due to a loss of business critical system or service, or due to severe usability problems with a large number of Customers. Please follow the Emergency Change Process. All required documentation (depending on type of Release) should be provided within 1 week following the deployment. |
Can be used for all Release Types |
How, When, Where, and by Whom is the Emergency determined? Why not just use Emergency for everything? Is the “Urgent” type required? How is Emergency audited? |
|
|
Release Categories |
Description |
|
|
Version |
Initial launch, change in location or platform, major application code re-write or architectural design, change in middleware service or infrastructure operation system |
|
Release |
Implementation of new functionality / application capabilities, addition of new infrastructure | |
|
Level |
Enhancement to, or revisions of, existing functionality, changes in application or existing infrastructure configuration (availability, capacity, SLA, or continuity) | |
|
Patch / Emergency Patch |
Only used for corrective actions. (Implementation of new functionality is not authorized) | |
|
Only used for restoration of service in case of existing service outage or avoidance of an imminent service outage. |