Open Cascade starts supporting maintenance releases of Open CASCADE Technology


Starting from February 2021 Open Cascade introduces into practice maintenance releases of Open CASCADE Technology (OCCT). This approach allows users to get the certified updates for OCCT and added-value components faster and at no additional costs. We consider maintenance release (or Maintenance Pack) as a release of a product that does not add new features or content. For instance, maintenance releases are typically intended to solve minor problems, such as “bugs" or documentation issues, etc.

We’ve prepared the first OCCT maintenance release (version 7.5.1) and are going to follow this approach on a regular basis. Starting from now, we plan to issue maintenance packs approximately once a quarter or even more frequently depending on the customers’ requests and our technical possibilities.

The sources of Open CASCADE Technology 7.5.1 are available under the V7_5_1 tag in the OCCT repository.

This maintenance release fixes the following critical problems:

  • 31845: Modeling Algorithms - BRepOffsetAPI_MakeThickSolid fails in OCCT 7.5.0 BETA [Regression]
  • 31912: Modeling Algorithms - Boolean Cut can't build resulting shape [blocking problem]
  • 32058: Modeling Data - Extrema curve-surface gives wrong result for planar surface of revolution and circle [child of 31912]

Publication date: 5 February 2021.

Roman Lygin's picture

Hello folks,
Will the maintenance releases x.y.z guarantee binary compatibility with x.y.0 ? It will be a nightmare if they do not.
Every annual release breaks source code compatibility and it takes multiple person-days (or -weeks) to migrate to To support several OCC versions at once our code is full of #ifdef's :-((.

Hope maintenance releases will not add additional headaches into that.

Thank you for consideration.


Forum supervisor's picture

Hello Roman,

No, they do not guarantee binary compatibility. In general, maintenance releases are dedicated to fixing particular problems of our customers. Nevertheless, we are trying to keep a stable public API. For example, 7.5.1 exactly meets this definition. It adds three patches on the top of 7.5.0 fixing critical issues of our customers. Public API is compatible with 7.5.0, but one of the patches adds additional private methods to the corresponding library. As a result, it is not binary compatible but doesn't require porting.

Roman Lygin's picture

Hello Forum supervisor,

Thank you for the response.

Adding a private (or even public) method does not break backward compatibility. In that sense 7.5.1 seems be guarantee binary compatibility which is good.

Please DO try to enforce the policy of the binary compatibility for x.y.z vs x.y.0 releases. This is a very reasonable expectation to a broadly used C++ library. You might want to learn more about what binary/source compatibility is and how to ensure that for the C++ libraries. You can just google for 'what is binary compatibility for C++ library' or something alike. One of the references is this paper (, which in its par.4.1 seems to offer a good strict summary of that.

Thank you for taking into account this request.


tonka's picture

Hi @everybody,

I would also love to see an ABI stable patch version of OCCT and 100% agree with Roman.

Just one question: Is the maintenance pack under the open source license like it was with the px releases or just in a paid tier?



Forum supervisor's picture

Hello Michael,

The sources of maintenance release are available in the OCCT repository under the open source license. However, binary versions are accessible for commercial clients only.

Roman Lygin's picture

[removed. reposted above]