☰
Navigation :

Migration notes 3.0

This page explains the changes required to migrate to the stated version of Atoti What-If.

Migrate to 3.0.4-AS6.0

Upgrading from version 3.0.3, see Atoti What-If 3.0.4-AS6.0 Release Notes.

No migration steps are required.

Migrate to 3.0.3-AS6.0

Upgrading from version 3.0.2, see Atoti What-If 3.0.3-AS6.0 Release Notes.

No migration steps are required.

Migrate to 3.0.2-AS6.0

Upgrading from version 3.0.1, see Atoti What-If 3.0.2-AS6.0 Release Notes.

No migration steps are required.

Migrate to 3.0.1-AS6.0

Upgrading from version 3.0.0, see Atoti What-If 3.0.1-AS6.0 Release Notes.

No migration steps are required.

Migrate to 3.0.0-AS6.0

Upgrading from version 3.0.0, see Atoti What-If 3.0.0-AS6.0 Release Notes.

Atoti What-If is using Atoti Server 6.0.11-sb3.

For new features and fixes included in these releases, please see the Release notes for Atoti Server.

Headline announcement

  • Java 17: Atoti What-If has been upgraded to Java 17.
  • Spring Boot 3.2: Atoti What-If has been upgraded to Spring Boot 3.2.
  • Atoti Server 6.0.11-sb3: Atoti What-If has been upgraded to Atoti Server 6.0.11-sb3.
  • Refactored deletion workflow: The branch deletion workflow has been redesigned to better fit UI use-cases.
  • Removed deprecated /version endpoint: The previously deprecated REST endpoint has been removed.

Version upgrades

Atoti What-If has been upgraded to Java 17, Spring Boot 3.2 ,and Atoti Server 6.0.11-sb3. This upgrade is not backwards compatible and therefore will require a similar upgrade on the application side.

As part of the Java 17 upgrade, any javax packages and properties have been migrated to jakarta.

Deletion workflow changes

To fit UI use-cases better, the branch deletion workflow in Atoti What-If has been modified to allow for clearer status changes. The workflow now consists of:

  • A check for simulation deletion authorization - this can result in the UNAUTHORIZED status.
  • The deletion of all simulations contained in the branch - any failure will set the deletion as FAILED.
  • A check for branch deletion authorization (through a combination of branch permissions and simulation security management) - this can result in the UNAUTHORIZED status.
  • The deletion of the branch - any failure will set the deletion as FAILED.