Core Engine (4.38)

# Product Lifecycle

The 4ALLPORTAL is continuously improved and its 4Apps are upgraded regularly.

When upgrading a 4App, we follow semantic versioning:

  • Patch versions (X.X.1) fix bugs
  • Minor versions (X.1.X) add functionality (i.e. new features and improvements)
  • Major versions (1.X.X) mean incompatible breaking changes (i.e. removal of API endpoints)

Both patch and minor version aim to be backwards compatible.

A minor version can be an STS (Short Term Support) or LTS (Long Term Support) version.
Both release versions get our support, but the support length differs. So how long will there be patches for a version and what bugs will be patched?

# Release Channels (Cloud Systems)

If your system is running in a cloud, it will be automatically updated with new 4App upgrades. The timing of the update depends on the release channel set for your cloud system:

  • "Release": Systems that are set to the "Release" channel will be updated as soon as a new version of a 4App is available.
  • "Late": Systems that are set to the "Late" channel will be updated 14 days after as a new version of a 4App is available. If a patch version is released within this time, the 14 days will start counting again from the patch release date.

By default, productive systems are set to the "Late" channel, and test systems are set to the "Release" channel.
You can change the channel if you wish (but your productive system should always remain in the "Late" channel).

# STS Version

  • STS stands for Short Term Support.
  • All released major and minor versions are STS versions (exceptions are specially marked LTS versions, see below).
  • Support length: An STS version is supported from its release date until 8 weeks after the release of the next minor version.

What bug fixes will be backported to the "old" STS within these 8 weeks?

  • All security bugs
  • All functional bugs of level high or highest
  • All compatibility bugs of level high or highest

# LTS Version

  • LTS stands for Long Term Support.
  • An LTS version is a specially defined minor version (e.g. 3.6).
  • Support length: An LTS version is supported twelve months after the release of the next LTS version (time frame for upgrade implementations).

What bug fixes will be backported to the "old" LTS version within these 12 months?

  • All security bugs
  • All functional bugs of level high or highest
  • All compatibility bugs of level high or highest

An LTS version always has a minimum support duration of 18 months.

# What Minor Release will Become an LTS?

We designate an already released version as an LTS version. This is usually the last minor of a major version, i.e. the version before the next major with breaking changes is released. We thus ensure a backward compatible version with the highest minor feature set is available for a longer period.

An LTS is bound to a Major.Minor (1.1.X) version. Only patch versions can be created (e.g. 3.6.5, 3.6.6, etc.).

# Bug Types

We classify our bugs by nature into

  • Functional defects (functional requirements not met)
  • Performance defects (bad speed, stability, response time etc.)
  • Usability defects (bad UX)
  • Compatibility defects (bad compatibility with software, hardware, connectors etc.)
  • Security defects (system weakness prone to attacks)

More details (external link) (opens new window)

# Breaking Changes: New Major Release

Breaking changes are backward incompatible interface changes caused by turning off deprecated functionality, concerning e.g. our RESTful API, the general configuration scheme or general user interface.

If functionality shall expire, it is set to "deprecated". The required migration e.g. of connectors can be planned. With the final removing of deprecated code (i.e. making breaking changes), a new major version is released.

Please note: The support duration of STS and LTS versions is guaranteed.

# Product Information Sources

← Setting up a 4ALLPORTAL →

Request missing documentation