This page describes the logical (without tooling support) process of release planning and release execution in inspectIT.

Release planning

inspectIT development is planned using major versions (1.6, 1.7, 2.0).

In order to be able to realize big features (Epics) we plan these features to major versions. This planning step is important, so that we can adress bigger changes or improvements without being hindered by "all the small changes". We do not want to plan every small improvement at the start of a major version. We want to be very flexible and be able to change (add and remove) features and issues from/to major releases. We provide at least two features (or improvement) that the end-user can experience in each release.

In order to regularly deliver value to our users, we plan to deliver increments of a major release regularly. The point in time is flexible and depending on the importance of features added or bugs being fixed. We plan to release these preview releases (see Release types) at maximum every 3 month. As soon as we think that the number the preview version of a logical major version add enough features and address the epic features initially planned for the release, we release a major version as stable release.

This basically means, that we are always developing intermediate releases and label them as being "a preview" (not yet finished the major version) or as "stable" (the development branch is feature complete, without any loose ends)

Release a version

When releasing a version, the most important information is whether this is a preview release or the final (stable) release of this major version (see Release types). Executing a release is done via our Continuous Integration system. We developed a special Jenkins plugin - Jenkins Release Publisher Plugin - to automatically create new versions in Jira, create the release notes, upload to GitHub Release and other things.

Releasing a preview version

Whether or not to release a new preview version, ask yourself the following questions. If you answer any (or all of them) with yes it might be a good time to release a preview version. We do not want to have a "must" clause for preview versions.

Is the last release (preview or major) more than 4 month ago?
Did we fix some major bugs that will address lots of users?
Did we implement new features that will help users in lots of situations?
Did we fix a bug or integrate a feature one specific project is asking for?

During the sprint review (describe) we discuss whether or not a preview version is released. If we see that none of the previous questions are answered with yes, we do not release a preview release.

Describe how we use the sprints and how this is aligned with releasing preview versions and stable versions

When releasing a preview version, the next version will keep the same major numbering, but the releasenumber will be increased by one (e.g. releasing 1.5.2 as preview release will create a new version 1.5.3)

Releasing a stable version

A major version must only be release if all of the following points are true:

Explorative Testing was planned and performed.
All Blocker or critical bugs that were scheduled with this major version are fixed (see Bug Classification Process)
All epic features that were planned with this version were realized (or moved to another major version).

Releasing a major version, the next version will increase the major number by 1 and set the releasenumber to 0 (e.g. releasing 1.5.2 as major release will create a new version 1.6.0)