Mon, 07/21/2014 - 17:13
Forums:
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"
Mon, 07/21/2014 - 17:48
Hello,
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.
Andrey
P.S. Note that fix for #25075 is already in master
Mon, 07/21/2014 - 19:26
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
Sebastian
Thu, 09/04/2014 - 13:08
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 6.8.0.dev, not 6.7.3.dev as it is now. This should be corrected in the next integration (likely tomorrow).
The approach we adopted to version numbering is as follows:
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
Andrey
Fri, 11/21/2014 - 20:23
I just realized that OCE started putting their version info into OCC_VERSION_DEVELOPMENT
https://github.com/tpaviot/oce/commit/9314eff347b03c6b5f34033b6c517c8373...
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.
Mon, 11/24/2014 - 09:29
Good point, thank you for noting!