Concept of storing and retrieving the release version

The requirement are described within INSPECTIT-2

Requirements

For reasons of traceability, the information about the concrete release version is very important. Think about bug reports in which this release information can give the clue as to whether or not the bug is already fixed with a newer version.

Approach

The release version is integrated with the Hudson release process. Hudson allows to manage parameterized builds. Before the start of a parameterized build the user is asked to provide the parameter. This parameter is then passed on to the build scripts. Thus we create the version in the following way: [logicalnumber].[internal hudson build], where

• logicalnumber is provided by the user as a parameter to the release build (e.g. "1.0" or "1.1")
• internal hudson build number is automatically always increased by Hudson itself, thus we can create a version 1.0 multiple times and still be able to differentiate between them.

This version is also saved to a file that is accessed by the application using the Classloader.getResource facility:

InputStream s = [...]getClassLoader().getResourceAsStream(VERSION_LOG_NAME)("version.log");
BufferedReader reader = new BufferedReader(new InputStreamReader(s));
String version = reader.readLine();

This code is integrated with the Commons project as this project is shared between all components (UI, CMR, Agent). Thus we only need to implement the functionality in one place.

Integration

This brief chapter describes the integration of the versioning information

Agent

• The registration service was adapted to provide the agent version to the CMR. The version is not used to check if a new platform ident is issued
• The versioning service is integrated with the pico container and used within
  • The agent startup to provide the current version to standard out
  • The IdManager to sent the current agent version to the CMR during registration
• The PlatformIdent dataobject is extended to provide the version of the agent.

CMR

• The versioning service is integrated with Spring as new bean
• The ServerStatus service that is called by the UI is extended to also provide the version of the CMR

UI

• Currently we use a standard about widget of Eclipse to show the about screen
• This widget needs the information to be available within the file plugin.properties in the root of the inspectIT project
• Thus the versioning service is not used for the UI, but the release process will instead write the versioning directly to this file

The release process

The release process job in Hudson will do the following:

• Create the version.log file, add the current version and put this file to Commons/src
  • The internal build file will integrate the version.log in the final archive if it is found here
• It will create the plugin.properties for the displayal of the version information for the UI

Presentation of the version

To allow the user to quickly retrieve the release versions of the three components (UI, Agent, CMR), the graphical user interface provides a means to display this information

Show Agent version

The agent version is integrated in the explorer view of the UI. The root element of the agent (displaying the agent name) will show the agent release version in brackets afterwards.

To attain the agents release version, the communication between the Agent and the CMR must be adapted. The agent must read its release properties file at startup and report its release version during the registration process. The CMR must then store this information and provide this information with the agent DTO.

Show CMR version

The CMR version is integrated in the explorer view of the UI. The CMR element must provide the release version in brackets (possible in a second line). Thus the CMR must send its version to the Agent.

Show UI version

The UI version of the Client should be shown in the title and by clicking on the help entry.