Long-Term Support
MidPoint support model is based on releases that have different support lifecycle:
-
Feature releases: Ordinary releases, rapid development pace. Goal of feature release is to move midPoint forward in terms of functionality. Therefore, feature releases include new features and improvements. Of course, there are also bugfixes. The feature release undergo the usual QA cycles, therefore they are stable and perfectly suitable for production use. Just the ratio of features to bugfixes is set in favor of new features. The support lifetime of a feature release is relatively short. In fact, the support lifetime is only meant to give deployment a change to upgrade to a new feature release with sufficient time overlap. Feature releases are meant to be continually upgraded.
-
Long-term support (LTS) releases: Releases designed for a long-term operation. These releases still contain new features and improvements. However, the primary goal is stability, compatibility and long-term sustainability. LTS releases are likely to bring bugfixes and stability improvements in greater-than-usual proportions. The QA process for LTS releases is intensified, and it is also expected that there will be several maintenance releases following an LTS release. LTS release have longer support lifetime, which can be further extended if needed.
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. Such maintenance release are not prolonging the support lifetime. Once the original (minor/major) release is at the end of support lifetime, 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.
|
Release process and versioning
For the explanation of midPoint release process, versioning scheme and other technical details about midPoint releases please see the versioning page. |
Maintenance Releases
Maintenance releases (e.g. midPoint 4.1.1 release) are the releases that bring bugfixes after major/minor release. Maintenance release do have any fixed schedule, they are released as needed. 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 of midPoint.
This approach does not mean that we are going to hide the bugfixes or anything like that. MidPoint is open, and it will remain completely open. The bugfixes are still be available on the support branches. We will just not go through the additional process of bundling them in an official release unless it is really necessary. Maintenance releases may not even be necessary for feature releases 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 releases may be needed due to the long lifetime of a LTS release.
Upgrade Path
There is always an upgrade path from one major/minor release to the major/minor release that immediately follows it. E.g., midPoint 4.0 can be upgraded to midPoint 4.1 and then to midPoint 4.2 and so on.
However, there is an additional and direct upgrade path between LTS releases. An LTS release can be directly upgraded to the next LTS release. There is no need to go through the upgrade to all the intermediary feature releases.
| Upgrade to the latest maintenance version available for your release first! Consult LTS release notes to know what is the minimal version needed to have the best upgrade experience. Otherwise, some pre-upgrade checks will not be available and you may miss some deprecations warnings, etc. |
MidPoint compatibility model is 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. We may end up in a maintenance hell otherwise, 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. The bugs will still get fixed, even in LTS releases. However, for LTS release, there is likely to be a configuration option or a workaround that may enable the old behavior. 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. While the 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. 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. 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 before it actually disappears. 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. 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 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.
Extended Support
Lifetime of LTS releases is designed in such a way that it provides sufficient overlap with a next LTS release. We strongly recommend upgrading 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. However, there are limitations:
-
Extended support is (significantly) more expensive than ordinary support.
-
Extended support is only available for an LTS version, and it must be negotiated while that particular version is still in its support interval (before its end-of-life).
-
Only fixes that aim at major problems of the customer with an extended support can be backported to the support branch after the end of ordinary support interval. There will be no features or improvements. Only the fixes - and only those fixes that affect production environments of supported deployments in a non-negligible way.
-
Fixes for cosmetic problems that do not affect the deployment in a significant way may be refused during extended support.
-
Problems that have a practical workaround will not be fixed as part of extended support.
Summary
| 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 |
Frequently Asked Questions
I have requested a feature. In which version it will be delivered?
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. For platform subscribers it 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. In some cases, the plan is already set for several releases to come. Platform subscribers have priority. However, 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.
|
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. However, 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. 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 your feature will be developed is to get platform subscription. |
History
The LTS program became effective in 2019 with the release of midPoint 4.0. MidPoint 4.0 is the first LTS release.
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 are 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. 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. 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. That was the start of LTS support program.