1. www.itu.dk 1 Release Management Hohmann Chapter 15

2. www.itu.dk 2 Purpose of Release Management Customers need to know –Which version of a system should be ordered –Which version is compatible with previous versions, the patches and/or upgrades that are available –What order to apply patches and upgrades

3. www.itu.dk 3 Terminology TermDefinition Program family The total of all product components ComponentThe smallest discrete entity identified in the system. Each component distributed to a customer must be versioned VersionA fixed or “frozen” component. Must be possible to re-create if distributed derived from source (manual/object code)

4. www.itu.dk 4 Terminology TermDefinition RevisionA new version of a component made to supersede the old. Usually consequentially numbered VariationAn alternative implementation of a component (e.g., to support different target operating systems) DistributionA version created for distribution to a set of customers ReleaseA named and versioned collection of components that have been certified

5. www.itu.dk 5 Release Identification Complete Release No universal ID scheme One systematic approach: –The name of the product –A four digit tuple x.y.z.build to capture revision information –An arbitrary number of variation identifiers x.y.z.build –x: Major release. Customer visible change: API, functionality, supported tools. Marked driven due to support –y: Minor release. Usually new features –z: dot release. Maintenance release –Build: Source build id. Normally not shown to customers to avoid too frequent change of documentation

6. www.itu.dk 6 Release Identification Partial Release Usually partial releases are market driven. Customers can be a part of the product Should evolve under its own x.y.z.build scheme A key issue is to manage dependencies between partial releases and complete releases. –A partial release x.y.*.* should be compatible with complete release x.y.*.*

7. www.itu.dk 7 Release Identification Patch Release Usually due to emotional events (bugs) No evolve scheme since one time event Patch name should be closely related to the associated release –E.g., “Superdraw 4.5 long documents patch”. Means that the patch can be applied to any Superdraw 4.5.* release

8. www.itu.dk 8 Release Identification Variations Releases Also no increasing version number since they are alternatives Name should be appropriately merged with the name of the associated release –E.g., “Superdraw 4.5 for Linux”