Page tree
Skip to end of metadata
Go to start of metadata

MidPoint is designed to be upgradeable. MidPoint has a semi-fixed release cycle with two releases per year therefore upgradeability from one version to another is critical. MidPoint has a built-in tools to support the upgrades as well as every minor release contains database scripts and upgrade instructions. We also recommend to all our partners to offer free upgrades of midPoint to their customers at least once per year.

MidPoint Releases and Upgradability

There are three types of midPoint releases. The upgradeability of each particular release type is different.

  • Maintenance and patch releases (e.g. version 2.4.2): The upgrade is trivial. There are usually no changes to the database structure and there are only compatible changes to the data model. Therefore it is usually sufficient to replace the software (e.g. redeploy WAR file) and that's it. In some cases it may be needed to run a database script to extend the tables with new columns. But no data migration is necessary.
  • Minor release (e.g. version 2.4): The upgrade is easy and it is a routine task. As minor releases are introducing new features the changes to a data model are expected. But the changes are backwards compatible. Therefore there is usually no need to change midPoint configuration at all. It is usually enough to run a database script to adjust the database structure. In a very rare cases an export and re-import of the data may be needed (e.g. in case that the database structure was re-optimized for performance and needs to be re-initialized).
  • Major release (e.g. version 3.0). The upgrade may be challenging. Major releases are big leaps in midPoint development. Such releases bring new and unique functionality, change of paradigms and general evolution of the software. We try very hard to avoid incompatible changes during midPoint development. Bit it is usually not possible to both maintain strict compatibility and efficiently develop new exciting features. Therefore we provide a compromise: compatibility is kept for minor releases. But we relax that requirement for major releases to allow efficient evolution of the product. As major releases happen only once per 2-5 years this strategy is acceptable both from maintenance and software development point of view.

The important thing to remember is that there is always an upgrade path for deployment that have midPoint subscription. Even for major releases.  The only difference is the difficulty of individual upgrades. MidPoint protects your investment. Your work on midPoint configuration will never be ruined by upgrading from one release to another. Even if there are major changes and parts of functionality are dropped you will have enough time to adapt to the change (see below).

Upgrades to maintenance and minor versions from the latest available version are supported for all midPoint users as part of their normal support schedule (subscription or community support). However upgrades to major versions are supported only for users with valid midPoint subscription. And this only applies to subscribers that had valid subscription at least 3 months before the planned date of midPoint major release. This is no arbitrary business limitation. There are solid technological reasons for this. The major version brings big pieces of new functionality which usually requires re-egineering of some midPoint parts. This is natural part of sustainable software development process. However re-engineering usually also means cleaning up old things. Some of the older (deprecated) features are removed from the system as part of that re-engineering. This is required to handle the complexity and to keep midPoint maintainable in a long run. But when we remove parts of the functionality we need to estimate the impact that this removal will have on upgradeability. And we can estimate that only for midPoint deployments that we know about. And we only know about the deployments that are covered by subscription during the time that we make re-engineering decisions (hence the "3 months ahead" limitation). Therefore we can only guarantee upgradeability for long-term midPoint subscribers. The upgrade process may work also for deployments without a subscription. Or it may not. We cannot make any promises for non-subscribed deployments because we simply do not have enough data about them and therefore we are not able to estimate the impact.

Upgrade Support and Subscription

Upgradeability may look like an easy thing to do. But it is not. In fact it is one of the most difficult parts of software lifecycle management. Especially when it comes to upgrades of such a complex and flexible piece of software as all Identity Management products tend to be. We have done our best in midPoint to support smooth upgradeability. We have a support for data structures that are independent of actual database structure. We have support for namespaces which reduces the risk of conflicting extensions and new midPoint features. The namespaces also properly support data format versioning. And many more features that are unique in both identity management field and also in open source software in general. These features contribute to a relatively easy upgrades of maintenance and minor releases.

Major releases are different than any other releases. Despite all of the technologies the upgrade problem is still not an easy one when the feature set changes. MidPoint has a lot of features and huge number of possible combinations of configuration settings. It is very difficult not to forget something, to test the upgrade of all the features. It requires a lot of testing and only a small portion of that testing can be done in the laboratory. Therefore some of the upgradeability testing needs to be done with real configuration of pilot deployments. Therefore for major releases the upgrade procedure is not available at the same time as the release. Major releases are at the time of the release intended only for new deployments. The upgrade procedure for a major release will be announced separately and it will come later after the release. As the upgrade tests for a major release are done with the real configurations from real deployments we cannot even make the instruction public until they are tested and generalized. We try really hard to keep the open source character of midPoint project. But this is one limitation that we need to live with. It is not that we do not want to make this public at the day one. The reason is that we respect our customers and from that point of view we just cannot make this public until it is sufficiently generic.

The upgrade for deployments that have valid midPoint subscription is available immediately after release in a form of a service. Even though generic instructions may not be available yet we can produce customized upgrade instruction for subscribed deployments on request and we can also provide assistance during the upgrade.

The only universally supported upgrade path to any specific release is from the most recent previous release. E.g. the upgrade path may look like this: 1.9 -> 2.0 -> 2.1 -> 2.2 -> 2.2.1 -> 3.0 -> 3.1. In other words the universally supported upgrade path is linear. This is the only upgrade path which we support under the community support model. However midPoint subscribers have the ability to request other (custom) upgrade paths. E.g. upgrade from 2.1 directly to 3.0. Upon a request from a subscriber we will provide migration scripts and procedures from any release to any other release provided that such migration path is technically feasible.

Support Duration

Community support applies only to the most recent released version. This is the only version that is supported under community support program. Also the bugfixes reported for this version are normally included in the current development version. Therefore the issues of the current midPoint version will be fixed in the next minor or major version. Fixes based on reports from the community will not be backported to the maintenance (support) branch. The only exception are security issues and critical functionality bugs. Such fixes may be included in the next maintenance release.

Longer support is provided to midPoint subscribers. We provide standard support for four most recent releases (not counting maintenance releases). E.g. if version 3.0 is the most recent version then the supported versions are 3.0, 2.2 (also 2.2.1), 2.1 and 2.0. Given the recommendation to upgrade midPoint approx. once per year and the ease of minor version upgrades this schedule gives a reasonable time for continuous and sustainable product support. Longer support agreements are available on request but these are usually more expensive. MidPoint subscribers also have the right to request backport of a bugfix to the support branch and therefore inclusion of that fix in the next maintenance or patch version.

Some midPoint features may become obsolete over time. When a feature becomes obsolete it will be marked as deprecated but it is not removed immediately. The feature will remain operational for at least three minor versions. The feature may be removed in fourth (or any later) minor version after the version in which it was marked as deprecated. The feature may also be removed in the major version if it comes earlier than the fourth minor version.

See Also

  • No labels