Product Lifecycle

The 4ALLPORTAL is continuously improved and its 4Apps are upgraded regularly. We follow a continuous deployment process: there are no separate support tracks (such as STS or LTS versions) — instead, all systems stay up to date via release channels.

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 large changes that make existing 4Apps incompatible with the Java API (see Breaking Changes)

Both patch and minor version aim to be backwards compatible.

Release Channels

Rollouts are performed in channels. The timing of an update depends on the release channel set for your system:

• "Snapshot": Development versions, published several times a day. Intended for development purposes only — never for staging or production systems.
• "Release": New versions are rolled out in two-week cycles. This channel is usually configured for a staging environment.
• "Late": Follows the "Release" channel with a two-week delay. This channel is usually configured for the production environment. If any irregularities are observed during the rollout, the update is delayed further until they are resolved.

Security and stability patches are rolled out to all channels as needed, independently of the regular cycle.

By default, productive systems are set to the "Late" channel, and test/staging 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).

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)

Breaking Changes

Breaking changes are backward incompatible interface changes, concerning e.g. our RESTful API, the general configuration scheme or general user interface.

Before a breaking change is carried out, we check whether the affected functionality is actually in use. It is only carried out directly if the functionality is not used. Otherwise, a migration or alternative is coordinated with the system administrator six months in advance.

If functionality shall expire, it is set to "deprecated" first, so the required migration (e.g. of connectors) can be planned.

Major Releases

A new major version is released for large changes that make existing 4Apps incompatible with the Java API. For these changes, a transition window with deprecated functionality is not possible: all affected 4Apps must be upgraded to a compatible version together with the new major version.

Product Information Sources

• Refer to our Product Roadmap for more information on the current development.
• Refer to our Release Notes for information on released 4App versions.
• Refer to our technical documentation and our user guide.