LIFECYCLE SCHEME

The lifecycle of Greenbone OS release follows a distinct graduated scheme. In doing so, we take care of:

• Stability of each release
• Seamless and simple migration path
• Comfortable way to the technological state of the art

Greenbone OS Lifecycle Phases

• Planning: during the planning phase we also consider any wishes and proposals of our customers for new or extended functionalities.
• Development: some new functionalities are implemented, some are still in progress. The final feature set is still open to be determined. As soon as a upcoming release enters this phase, it appears on our Roadmap.
• Alpha: a first version of the new Greenbone OS is assembled and handed over to an internal test group. It is still possible to add further functionalities, but adding larger ones needs to be justified. The first QA system for this release is set up and will be active until the retirement of the release.
• Beta: the feature set is now fixed. The new Greenbone OS is made available to an extended group of testers, including selected partners and customers.
• New: the new release is available for some GSMs, but not all yet. Step by step, all GSMs will be supported during this phase. The new release is removed from the roadmap and appears on the page Greenbone OS: Current.
• Mature: any existing GSMs can now be migrated to the new release.
• End-of-Life: as soon as a date for the End-of-Life is published, the release enters the End-of-Life phase. Users are encouraged to upgrade to a newer release.
• Retired: the End-of-Life date is reached. Such an old version may still be present on some flash system and reactivated via a factory reset. In that case, the upgrading to a new release is still supported.
  The release now leaves the QA process. The corresponding QA systems are finally switched off. The release is also removed from the list of current releases and moved into the Archive.
• Obsolete: no support whatsoever anymore.

Greenbone OS Lifecycle Levels

• Patch Level: the last number of a GOS version indicates the patch level, e.g., “21” in “3.0.21”. Prior to GOS 3.0, the patch level was indicated with a dash (e.g., “2.0.0-21”).
  Always the newest patch level is fully supported within a release. For all previous patch levels the upgrade to the newest patch level is supported. A patch level upgrade will not change any default behavior. Neither will it introduce major changes of functionality.
  Information about the newest patch levels is made available via the newsletter and via the page Greenbone OS: Current.
  The intention of patch level upgrades are bug fixes and minor new feature as long as they do not require migration or API changes. In addition to this, Greenbone OS security upgrades are managed via patch level upgrades.
  Patch level upgrades are executed easily. Prior to opening a new support ticket, you should always verify the defect is present with the newest patch level.
  The counting of patch levels starts with 0. The first patch level of a new release (for example 3.0.0) is the first alpha version. Before a new release reaches the customers, the patch level counter reflects the number of alpha and beta iterations.

• Release: the middle number of a GOS version indicates the release, e.g., “0” in “3.0.21”.
  Within a generation all releases are supported for some time. Once it is clear that the next release will also be the next generation, the latest release of the generation becomes subject to Longterm Support (LTS Release) while the older releases of that generation are only supported with regard to upgrading to the LTS release. GOS 2.2, for example, is a LTS release because the next release included a change to the next generation, GOS 3.0. In this case, the support for GOS 2.0 and GOS 2.1 ended earlier than for GOS 2.2.
  The End-of-Life of a release is always announced at least 3 month in advance, for a LTS release even 6 month in advance. The newsletter will regularly inform about such deadlines and all states and deadlines can be reviewed at any time on this page: Greenbone OS: Current.
  The intention of a release is the introduction of new functionalities and the extension of existing ones. This may even include changes of the default behavior. Subject are the scanner itself, the web interface, the API and the administration. The upgrade of the flash system of hardware-based GSMs is typically not subject for a release. Migration of the database is usually mandatory and will be executed automatically.
  Because a release upgrade means considerable changes, the administrator must explicitly select a release change. If this is done, the release upgrade is done the same way as a regular patch level upgrade.

• Generation: the first number of a GOS version indicates the generation, e.g., “3” in “3.0.21”.
  The End-of-Life of a generation happens never earlier than at least one year after the following generation was released to the users. Another precondition is the presence of a flash upgrade and a guide for upgrading and migrating to the next generation.
  The intention of a Greenbone OS generation is the introduction of an entirely new basis in order to provide the user with the newest state-of-the-art without making any compromises.
  Usually, with a new generation also the flash system of the GSM hardware is updated as well.