Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Background

All midPoint releases until 2018 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 sides. 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.

Long-Term Support (LTS)

The new model is based on releases that have different support lifecycle:

  • Feature releases: Ordinary releases, rapid development pace. Goal of
  • Long-term support (LTS) releases: TODO

Extended Support

TODO: extended support

Upgrade Path

TODO

Summary

 Release frequencyPrimary goalSupport intervalExtended support
Feature releaseapprox. every 6 monthsNew features1 yearno
Long-term support (LTS) releaseapprox. every 2 yearsStability3 yearsyes

 

Bootstrapping LTS Program

TODO

TODO: disclaimer ... THIS IS ALL PRELIMINARY, it may still change

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. 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.

 

See Also

  • No labels