You are on page 1of 5

19-Apr-04

AA-019 Version 1.0


EN
Page 1 of 5

Rules for Labels of Client


and Server

Table of Contents
1 General...............................................................................................................................................................................2
1.1 Purpose and Scope..........................................................................................................................................................2
1.2 References.......................................................................................................................................................................2
1.3 Definitions.........................................................................................................................................................................2

2 Rules for Labels of Client and Server..............................................................................................................................2


2.1 Scope of Labels................................................................................................................................................................2
2.2 Structure of official Labels.................................................................................................................................................3
2.3 Rules for Naming..............................................................................................................................................................3
2.4 Rules for Compatibilty.......................................................................................................................................................4
2.5 Procedure for Labeling and Checkpointing.......................................................................................................................4

created: checked: released:

Name: Name: Name:

Date: Date: Date:

Signature: Signature: Signature:

AA-019-EN Rules for Labels.sxw


19-Apr-04
AA-019
Rules for Labels of Client and Server Version 1.0
EN
Page 2 of 5

Change History
Comments Changed by Date Version State

First created Georg Will 19. 04.04 1.0 In process

1 General

1.1 Purpose and Scope


This document defines the rules for labels of clients and servers for products. For projects optionally
these rules also can be used.

1.2 References
none

1.3 Definitions
none

2 Rules for Labels of Client and Server

2.1 Scope of Labels


In general a label can have following scopes:
• Official delivery. This can be either a delivery to any customer or even a scheduled one, which for
any reasons finally will not be shipped.
• For internal use. An internal technical label can be set e. g. for milestones, internal deployment or
just saving an actual state. Such a label must not start with “V_” to distinguish between official
and internal labels.
Below only official labels will be handled.
19-Apr-04
AA-019
Rules for Labels of Client and Server Version 1.0
EN
Page 3 of 5

2.2 Structure of official Labels


A label should have a structure as follows:
V_<MajorRelease>_<MinorRelease>_<SubLevel>[b<BuildLevel>]
Note: b<BuildLevel> is optional.
Examples: V_4_2_0 or V_4_2_0b1.

Levels
A label consists of four levels:
• Major Release:
Related to a major product development step. This is normally valid, when new modules or big en-
hancements of existing ones are integrated.
Change in coordination with the sales department, which means, only sales can release such a
change.
• Minor Release:
Related to a minor product development step. Usage is also for enhancements.
Change in coordination with the sales department, which means, only sales can release such a
change.
• Sub Level:
This level is changed when we have changes on
- interfaces,
- database,
- documentation,
- enhancements (which are too big for a change on build level only) or
- changes of the functionality of the software.
This is important from the technical point of view, to ensure compatibility of components.
Change without coordination with sales.
• Build Level:
This level is changed by doing bugfixes or improvements. Changes as described in sub level may
not be done here, that means, related to compatibility no changes are allowed. A new build level
can only be released, if the functionality is not changed. Change without coordination with sales.

2.3 Rules for Naming


• Label starts with prefix “V_”.
Note: RCS based version controls systems like MKS and CVS do not accept labels starting with
digits.
• Each first release does not have a build level (e. g. release V_4_1_1, first bugfix build
V_4_1_1b1).
• Counting should start with 1 for major release and, if existing, for build level. For minor release
and sub level counting starts with 0.
• For each level there is no leading “0”. Build level starts with prefix “b”, but without underscore.
19-Apr-04
AA-019
Rules for Labels of Client and Server Version 1.0
EN
Page 4 of 5

• Increasing of version numbers:


Increasing one of the first three levels initializes version numbers of all lower levels. Example:
V_4_2_14b1 => V_4_3_0

2.4 Rules for Compatibilty


• In general interfaces should be downwardly compatible. If an interface changes, a new interface
should be created (fnc_2 etc.).
Further rules still have to be defined for this topic. Following issues in this section are just sugges-
tions for later!
• Client and server labels within one product must at least correspond on the first three levels (e. g.
client 4_1_1, server 4_1_1b1).
• Version check (target: should be implemented)
A) Inside one product:
Version check for component compatibility includes major release, minor release and sub level.
These levels have to match exactly.
B) Between products:
Optional a check for a minimum level could be used.

2.5 Procedure for Labeling and Checkpointing


Main target is, to ensure, that each version can be restored afterwards again. There are two possibili-
ties (depending on the work effort). The procedure to use has to be defined for each product seperate-
ly.
In general all files of a project should be labeled and checkpointed, if there is a change on (at least)
the levels major release, minor release or sub level.
What means “all files of a project” in that context? This means all own modules, all own clients and
servers. But without modules of other products or basic components, libraries (e. g. COMAN, any
jars), which only will be referenced (e. g. via makefile, xxx_versions.bat). Because of that also the in-
cluded foreign components are well defined.
Standard Labeling Method
For a change on any level of major release, minor release, sub level, build level all files will be la-
beled.
19-Apr-04
AA-019
Rules for Labels of Client and Server Version 1.0
EN
Page 5 of 5

Example for assigning labels:


Action file1.c file2.c file3.c Product Version
first release V_1_0_0 V_1_0_0 V_1_0_0 1.0
build V_1_0_0b1 V_1_0_0b1 V_1_0_0b1 1.0
(file2.c changed)
sub level V_1_0_1 V_1_0_1 V_1_0_1 1.0
sub level V_1_0_2 V_1_0_2 V_1_0_2 1.0
build V_1_0_2b1 V_1_0_2b1 V_1_0_2b1 1.0
(file1.c changed)
minor level V_1_1_0 V_1_1_0 V_1_1_0 1.1
major level V_2_0_0 V_2_0_0 V_2_0_0 2.0

Alternative Labeling Method


Optionally it is also possible like this:
• For major release, minor release, sub level all files will be labeled. It does not matter which files
have been changed.
• For build level only those files are getting a new label, which have been modified since last label
on any of the four levels.
Example for assigning labels:
Action file1.c file2.c file3.c Product Version
first release V_1_0_0 V_1_0_0 V_1_0_0 1.0
build <unchanged> V_1_0_0b1 <unchanged> 1.0
(file2.c changed)
build <unchanged> V_1_0_0b2 V_1_0_0b2 1.0
(file2.c, file3.c
changed)
build V_1_0_0b3 <unchanged> <unchanged> 1.0
(file1.c changed)
sub level V_1_0_1 V_1_0_1 V_1_0_1 1.0
sub level V_1_0_2 V_1_0_2 V_1_0_2 1.0
build V_1_0_2b1 <unchanged> <unchanged> 1.0
(file1.c changed)
minor level V_1_1_0 V_1_1_0 V_1_1_0 1.1
major level V_2_0_0 V_2_0_0 V_2_0_0 2.0