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.
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.
But major Major releases are slightly different . But despite 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.
TODO: we suport four most recent midPoint 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.
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). TODO: deprecated featuresE.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.