All midPoint releases until 2019 had uniform support lifetime of two years. That essentially means that midPoint subscriber was entitled to ask for a bugfix in any midPoint release that was less that two years old. That was simple and easy model to start with. But it also has its dark side. MidPoint has a rapid release rate. There at least two releases every year. That gives us at least 4 different releases to support at any given moment. Also, it is quite obvious that quality of the releases somehow vary. There are releases packed with new features and then there are releases aimed at stability. Also, we need to keep the codebase maintainable. Which means we need to regularly re-engineer (refactor) parts of midPoint. The re-engineered code is more up-to-date and more maintainable. But initially there might be slight fluctuations, e.g. changed behavior because we have removed bugs that were there for ages and some people actually relied on them.
There are deployments that take advantage of new midPoint features. People running those deployments love midPoint's rapid development pace. They have no problem upgrading midPoint every 6 months. And indeed, it seems there is a lot of deployments like this.
Then there are deployments that prefer stability. Maybe deployments that are somehow heavy on a customization side. Deployments that rely on specific corner cases. Deployments where organizational obstacles make it difficult to upgrade often. Those may easily miss the two-year support period.
Obviously, one size does not fit all. Therefore we have decided to change the support model.
The new model is based on releases that have different support lifecycle:
Support lifetime is applied to (minor/major) midPoint releases. Maintenance releases do not change support lifetime and they have no support lifetime of their own. Support lifetime begins with the release of (minor/major) midPoint versions, e.g. midPoint 4.1. That release is followed by maintenance releases (e.g. midPoint 4.1.1) that are released during the support lifetime of the (minor/major) version. Those maintenance release are not prolonging the support lifetime. Once the original (minor/major) release is at the end of support lifetime, the all the maintenance releases also become unsupported. Therefore once the support lifetime of midPoint 4.1 is over, the support ends also for versions 4.1.1, 4.1.2 any other maintenance release in the 4.1.x family.
For the explanation of midPoint release process, versioning scheme and other technical details about midPoint releases please see the Release Process page.
Maintenance release are the releases that bring bugfixes after a main release (e.g. midPoint 4.1.1 release). Maintenance release will be released as needed. But it is possible that for some feature releases there may be no maintenance release at all. On the other hand, we expect several maintenance releases for LTS versions.
This approach does not mean that we are going to hide the bugfixes or anything similar. MidPoint is open and it will remain completely open. The bugfixes will still be available on the support branches. We will just not go through the additional process of bundling them in an official release unless that is really necessary - for feature releases. Such maintenance releases may not even be necessary due to the short lifetime of a feature release. It may be easier to just upgrade to a next feature release directly.
For LTS releases it is very likely that several maintenance release may be needed due to the long lifetime of a LTS release.
The upgrade path from one release to the next release will be maintained. Therefore midPoint 4.0 can be upgraded to midPoint 4.1 and then to midPoint 4.2 and so on. No changes there.
However, there will be an additional and direct upgrade path between LTS releases. Therefore an LTS release can be directly upgraded to the next LTS release. There will be no need to go through the upgrade to all the intermediary feature releases.
MidPoint compatibility model will be maintained for all the releases. Therefore the things and configurations that worked in older release should also work the same way in a new release. Except for two cases: bugfix and deprecation.
We are not maintaining "bug compatibility". Bug is always a problem and it should be fixed. If something is wrong in midPoint then we will fix it. Even if it was wrong for ages and even if some people relied on wrong behavior. We are sorry, but in this case we prefer correctness and integrity over compatibility. Otherwise we may end up in a maintenance hell which may actually mean a dead end for entire product line. However, it is very likely that we will be more benevolent when it comes to LTS releases. Such bugs will still get fixed, even in LTS releases. But for LTS there is likely to be a configuration option or a workaround that may enable the old behavior. But this option only applies to LTS versions and to fixes backed by midPoint subscribers. There is no such option for feature releases.
The other case where strict compatibility do not apply is the case of deprecated functionality. MidPoint is an evolving system. And while vast majority of midPoint's functionality was well designed and it fits together perfectly, it is not possible to design such a comprehensive system without a few missteps. And also the world around midPoint is evolving and the requirements are changing all the time. Therefore there are few cases when we need to stop using old functionality and replace that with a better version. And in a very rare cases some parts of functionality that are no longer used may disappear altogether. In that case we are deprecating old functionality. Deprecated functionality still works and it is still fully supported. However, deprecated functionality may disappear in any subsequent midPoint version - whether it is feature release or LTS release.
This is also a reason for people that use only LTS versions should also watch feature releases. A functionality may be deprecated in one feature release and disappear in the following release. So, even if the functionality was not deprecated in old TLS release it may be missing from a new LTS release. This is a rare case, and in that case there should be a warning in the release notes of the new LTS release. But this case might happen. Therefore make sure to migrate away from deprecated functionality as soon as possible.
There is also an experimental functionality in midPoint. Experimental functionality is just that - experimental. It may change any time without any warning. It may even completely disappear. It is not supported under any stock support program (albeit it may be supported with a special contract). There are absolutely no guarantees when it comes to experimental functionality. Hic sunt leones. Use experimental functionality at your own risk only.
Please note that there are also major releases in midPoint development lifecycle. Major releases do not guarantee complete compatibility. In addition to that, it is quite likely that a major release will be also an LTS release. Therefore even though there will be a migration path between LTS releases, that migration path may not cover all the functionality of old LTS release. Some functionality is likely to be removed in major release. Therefore such migration path may include some manual steps that may require an attention of an experienced engineer.
Lifetime of LTS releases is designed in such a way that it provides sufficient overlap with a next LTS release. We strongly recommend to upgrade to a new LTS release as soon as possible. Direct LTS-to-LTS upgrade path is designed with the specific purpose to make this upgrade as smooth as possible.
However, there may be deployments that cannot upgrade and need even longer support than the one provided by LTS. For those deployments there is an option of an extended support. Extended support prolongs the support lifetime of an LTS release. Therefore an obsolete midPoint version can be used in production for a longer time and it can be fully supported. But there are limitations:
|Primary goal||Release frequency||Support interval||Extended support||Quality assurance and compatibility||Maintenance releases|
|Feature release||New features||approx. every 6 months||1 year||no||Ordinary||Only if necessary|
|Long-term support (LTS) release||Stability||approx. every 2 years||3 years||yes||Intensified||Yes, several maintenance releases planned|
The LTS program becomes effective with the release of midPoint 4.0. MidPoint 4.0 is the first LTS release.
If you have used your platform subscription to request a feature, the feature will be delivered in the next version where it can fit into a plan. This is usually the next planned version of midPoint - regardless whether it is feature release or LTS release. If it can fit into a plan then it will get into that release. And for platform subscribers is usually can fit into a plan, as other lower priority features move out to make space for subscriber features. However, there may be limitations. If you request a feature to a version for which development has already started then the plan may be already set and there may not be enough room for your feature. In that case you will need to wait for the next midPoint version. Similar thing may happen if you make your decision very close to a release. In that case the plan for the next release may be already set. Platform subscribers have priority. But if the plan is already saturated with subscriber features there is no room to move anything out. This does not happen often, but it may happen. Therefore please make your plans early and communicate your plans to us. Even if the plans are not definitive. If we are aware of your plans we may be able to reserve development resources for you. And we may fill in the details later.
This answer only applies to requests from midPoint platform subscribers or to customers with equivalent contracts (a.k.a. platform subscriber requests). Albeit anyone can technically request a feature, request from customers that do not have platform subscription (a.k.a. community requests) are considered to be low-priority requests. Such requests may still make it to development plan. But they may get displaced anytime, especially if there is request from a platform subscriber. Community request may be re-scheduled even if they have been already planned for a specific release. And in some cases, community requests may be re-scheduled even if the development of the feature has started. There are absolutely no guarantees when it comes to community requests. The only way to make sure that your feature will be developed is to get platform subscription.