Skip to end of banner
Go to start of banner

Release types

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

In the many years that we develop inspectIT we realized that our biggest challenge is to release a new publicly available version. We saw that we always want to integrate just one more issue. 

Release types

Stable release

A stable release finalizes a development branch (major version) of inspectIT. Thus a stable version is feature complete (for this development branch). All features are integrated and everything fits together. We intend this releases for customers that look for a stable base for application performance management with inspectIT. For each stable release we put a high effort in quality (see Explorative Testing)

Note that stable releases are usually released every 6-9 month. Thus the customer will not get new features directly. 

Preview release

Preview releases are intermediate releases during the development of the next major release. Preview releases are released as soon as development thinks that enough improvement for customers have been made. That is releases are created if important bug fixes were or a set of new features are integrated. We do ensure that preview releases are working and can be used by customers, we will also apply all testing steps. 

One of the biggest differences to stable releases is, that the goals for the development branch of the major version is not yet completely finished. This means that there are new features and improvements, but some other features that might work well with them are still missing. This makes the preview version sometimes feel "unfinished". 

Preview releases will be released approximately every 2 month, thus the customer can have a stable base and stay updated with the current features. 

Snapshot release

Snapshot releases are triggered every week and provide the current stable branch of inspectIT development. 

Versioning and naming schema

Each GA version uses an x.y schema for an unique version description. We currently do not intend to increase the leading x value often. Criteria of x is how big the step between this version and the last version was. As a rough guideline we intend to increase x perhaps once every few years. The release number is increased with every run of the GA or the preview release. The buildnumber is an automatically created number that is increased for every build. It is used to allow us to uniquely identify our releases.

Release typeVersion schemaVersion example
Major Release[majorversion].[releasenumber].[buildnumber]-GA1.6.4.78-GA
Beta Release[majorversion].[releasenumber].[buildnumber]-preview1.6.1.78-preview
Snapshot Release[majorversion].[releasenumber].[buildnumber]-Snapshot1.6.1.78-snapshot

 

During the discussions (Patrice BouilletStefan SieglIvan Senic), Ivan mentioned an interesting point. For him the advantage of the current release process was that the features integrated in the beginning are already quite stable, as we are using them for quite some time already. We concluded that this is true, but no reason for not having more releases. 

  • No labels