Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

MidPoint is software that is designed for easy upgradeability. We do our best to maintain strong backward compatibility of midPoint data model, configuration and system behavior. However, midPoint is also very flexible and comprehensive software system with a very rich data model. It is not humanly possible to test all the potential upgrade paths and scenarios. Also some changes in midPoint behavior are inevitable to maintain midPoint development pace. Therefore we can assure reliable midPoint upgrades only for midPoint subscribers. This section provides overall overview of the changes and upgrade procedures. Although we try to our best it is not possible to foresee all possible uses of midPoint. Therefore the information provided in this section are for information purposes only without any guarantees of completeness. In case of any doubts about upgrade or behavior changes please use services associated with midPoint subscription or purchase professional services.

Upgrade from midPoint 3.0, 3.1, 3.1.1, 3.2, 3.3, 3.3.1, 3.4, 3.4.1, 3.5, 3.5.1, 3.6

...

, 3.6.1, 3.7, 3.7.1 and 3.7.2

Upgrade path from MidPoint 3.0 goes through midPoint 3.1, 3.1.1, 3.2, 3.3, 3.4.1, 3.5.1 and , 3.6.1 and 3.7.2. Upgrade to midPoint 3.1 first. Then upgrade from midPoint 3.1 to 3.1.1, from 3.1.1 to 3.2 then to 3.3, then to 3.4.1, 3.5.1, 3.6.1, 3.7.1 2, 3.8 and finally to 3.89.

Upgrade from midPoint 3.8

...

MidPoint 3.9 data model is essentially backwards compatible with previous midPoint versions. However, there were changes that may affect some deployments:

  • Consistency mechanism in midPoint was update and aligned with manual connectors, taking into account possible future extension for asynchronous provisioning operations. Old shadow "consistency" properties (objectChange, result, attemptNumber, failedOperationType) are no longer used. Their content is ignored. All operations that are not completed immediately are now recorded in pendingOperation container.

Even though the basic database model is compatible with the previous versions, the underlying database schema was significantly modified due to performance and scalability improvements. Therefore the usual database-only upgrade procedure is not applicable for upgrades to midPoint 3.8. Export and import of the data is necessary in this case. Therefore following procedure has be followed for this upgrade:

  • Upgrade instructions from 3.7.1: Upgrade 3.7.1 to 3.8
  • TODO: make sure all postponed operations are finished before upgrade. Otherwise they will be lost.

MidPoint 3.8 is a release that fixes some issues of previous versions and there were also improvements to existing functionality. Therefore there are some changes that may not be strictly backward compatible with previous versions:

  • Version numbers of some bundled connectors have changed. Therefore connector references from the resource definitions that are using the bundled connectors need to be updated.

...

  • New resource capability (delta update) was introduced. Therefore please make sure that native resource capabilities are refreshed for resources that support delta update capability (most notably LDAP and AD connectors

...

  • ).

Changes in initial objects since 3.

...

8

MidPoint has a built-in set of "initial objects" that it will automatically create in the database if they are not present. This includes vital objects for the system to be configured (e.g. role superuser and user administrator). These objects may change in some midPoint releases. But to be conservative and to avoid configuration overwrite midPoint does not overwrite existing objects when they are already in the database. This may result in upgrade problems if the existing object contains configuration that is no longer supported in a new version. Therefore the following list contains a summary of changes to the initial objects in this midPoint release. The complete new set of initial objects is in the config/initial-objects directory in both the source and binary distributions. Although any problems caused by the change in initial objects is unlikely to occur, the implementors are advised to review the following list and assess the impact on case-by-case basis: 

...