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 realize bigger 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 beta releases (see Release planning) at max every 3 month. As soon as we think that the number the beta 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 GA (general availability) release.
This basically means, that we are always developing intermediate releases and label them as being "beta" (not yet finished the major version) or "major" (the last intermediate version for a major release)
Release a version
When releasing a version, the most important information is whether this is a beta release or the final (major) release of this major version (see Release planning).
Releasing a beta version
Whether or not to release a new beta 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 beta version. We do not want to have a "must" clause for beta versions.
- Is the last release (beta 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?
When releasing a beta 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 beta release will create a new version 1.5.3)
Releasing a major version
A major version must only be release if all of the following points are true:
- Release planning was planned and performed.
- All Blocker or critical bugs that were scheduled with this major version are fixed (see Release planning)
- 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 1 (e.g. releasing 1.5.2 as major release will create a new version 1.6.1)