shoogen's picture

What value should i define for OCC_VERSION_DEVELOPMENT
for a version of OCCT that includes patches from a "CR" branch, but have not undergone the certification process.
For example, currently i need to combine CR25088_1 and CR0025075 to get a useable version of OCCT.
"dev" would in my point of view not reflect that the version is actually not "certified"

abv's picture

Define your own string


In general, if you are working with specific branch / build of OCCT, I suggest you define OCC_VERSION_DEVELOPMENT to the string specific to you or your project, e.g. "shoogen". In this way everyone who get this version of OCCT will be able to distinguish it from the other builds.

However I deem that this makes sense only if you are going to distribute this version.


P.S. Note that fix for #25075 is already in master

shoogen's picture

Hello Andrey, thank you for

Hello Andrey,
thank you for your suggestion.

I saw that there is a 6.7.2 release branch. Will this version be publicly available?
Can i trust, that no Linux distribution will ever fall back with the version numbering behind the master branch?
For example: until last week, i used OCC_VERSION_HEX >= 0x060702 to test if CR CR0024911 is present in the build. But it would be a pity if a Linux distribution would pick my old code and OCCT V6.7.2. (This is a hypothetical example, since my code did not make it into our project because it was waiting for CR0025064)
Best Regards

abv's picture

6.7.2 was internal maintenance version, next release is 6.8.0

Hello Sebastian,

Sorry for my late reply!

Version 6.7.2 was tagged as internal maintenance release, made mostly for SALOME needs and providing only one patch over version 6.7.1. Since that patch will unlikely be important for other projects, we did not announced that version, and do not plan to make it official release.

The next scheduled release is 6.8.0, and you are right that we have some ambiguity in version number. Actually, current version of master branch should be marked as, not as it is now. This should be corrected in the next integration (likely tomorrow).

The approach we adopted to version numbering is as follows:

  • Each official release has three-digit version number, like 6.7.1; macro OCC_VERSION_DEVELOPMENT is not defined
  • Intermediate versions (development, beta, etc.) have version set to the next planned release (currently 6.8.0), and macro OCC_VERSION_DEVELOPMENT defined to some string ("dev", or "beta" etc.). This string is added at the end of the complete version string (macro OCC_VERSION_STRING_EXT) to indicate that it is not official release (e.g.

In general, you cannot rely on assumption that version number set in the current master branch will be always less than any consequent official release. It is possible, for instance, that we will have version 6.8.1 after 7.0.0, if needed for some reason. Thus you can make your code to support known releases, but there is no reliable way to ensure that your code will support future releases.

As for Linux distributions, they are prepared by community and unfortunately for the moment we do not have close collaboration with their maintainers, thus cannot be sure what version policy they follow. Most likely you will find that Linux distribution has version number equal to that of official release of OCCT, while the code may contain differences. Thus you need to check each case on its own. I hope the situation will be improved in the future.

Hope this helps


shoogen's picture


I just realized that OCE started putting their version info into OCC_VERSION_DEVELOPMENT
This will enable to distinguish the OCE releases from certified releases. Which is particularly helpful if OCCT/OCE was shipped by a linux distribution's package manager.

abv's picture

Good point, thank you for

Good point, thank you for noting!

Copyright 2011-2017
Contact us