...
inspectIT development is planned using major versions (1.6, 1.7, 2.0).
In order to be able to realize bigger 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 beta preview releases (see Release types) at max maximum every 3 month. As soon as we think that the number the beta 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 GA (general availability) stable release.
This basically means, that we are always developing intermediate releases and label them as being "betaa preview" (not yet finished the major version) or as "majorstable" (the last intermediate version for a major releasedevelopment branch is feature complete, without any loose ends)
Release a version
When releasing a version, the most important information is whether this is a beta preview release or the final (majorstable) 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 beta 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 beta preview version. We do not want to have a "must" clause for beta preview versions.
- Is the last release (beta 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 beta 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 beta 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:
- Release planningExplorative Testing was planned and performed.
- All Blocker or critical bugs that were scheduled with this major version are fixed (see Release planningBug 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 1 0 (e.g. releasing 1.5.2 as major release will create a new version 1.6.10)