Development of Gutenberg, Part 1

MidPoint 4.0, code-named Gutenberg will be major milestone in midPoint evolution. As the version numbering suggests, 4.0 is a major release. Therefore, there will be substantial changes that we have planned for quite some time. It will also be our first long-term support (LTS) release. Therefore, similarly to the invention of Johannes Gutenberg, the expectations are quite high.

It is planned that Gutenberg will be a long-term support (LTS) release. Which means that we will have to support this particular version for many years to come. Therefore, it is perhaps quite natural that the primary focus of 4.0 release is stability and internal quality. This coincides quite nicely with 4.0 being a major release. Therefore, we can make interface and schema changes that are not bound by strict compatibility. Nobody is perfect – and even though we try really hard we still make mistakes. Bugs in a code are easy to fix and we are doing that all the time. But then there are mistakes in interfaces and schemas. Those are difficult to fix due to the impact on compatibility. During normal (minor) midPoint releases we are bound by compatibility. Therefore, we deprecate things that are wrong, but do not remove them. But we do not want to accumulate too much rubbish in midPoint as that would be an obstacle to evolution. Therefore, the major release is a long-awaited moment in midPoint development – an opportunity for a development team to clean up the ground for a new midPoint generation.

However, those internal clean-ups are not entirely internal. For example we plan to clean up the interfaces to our “data layer” (a.k.a. Prism). This task should make midPoint development more straightforward. Which also means that extending midPoint and contributing to midPoint code base should be easier. Yet another planned clean-up is in the UI part of midPoint code. This clean-up should allow better extensibility of midPoint user interface using a custom code. There are few more activities with similar goals. In addition to cleaning up the code there are other activities that should help midPoint 4.0 to survive for a long time. First of all, we plan to support Java 11, which is also the first new-age Java release with a long support lifetime. We will be also upgrading all midPoint dependencies to latest stable versions in order to be ready to live with them for a long time. All of that is meant to improve midPoint internal quality. But also to extend midPoint support lifetime and make midPoint more customizable.

Leave a Reply

Your email address will not be published.