Versioning scheme used by Rhino SDK

Rhino Developer
, ,
1

Dear Sir / Madame,

I would like to know what the compatibility guarantees are between versions of the SDK as well as betwen plugins compiled using the SDK and Rhinoceros versions.

For example, if I compile a plugin using version 6.x of the SDK, is it guaranteed to be compatible with any version 6.y, in which y > x? In other words, does the SDK respect backwards compatibility within major versions?

And regarding compatibility between SDK versions and Rhinoceros versions, is any plugin compiled with version 6.x compatible with any other version of Rhinoceros version 6.y?

Kind regards,
Erik Valkering
Software Engineer at Mindesk

2

Hi @e.valkering

Plug-ins build with the Rhino 6 C++ SDK are forward compatible, but not backwards compatible, with new Rhino 6 service releases.

That is, a plug-in build with the 6.x version Rhino 6 C/C++ SDK will load and run in Rhino 6.x, 6.x+1 … 6.x+n.

A plug-in build with the 6.x version Rhino 6 C/C++ SDK, however, will neither load nor run in Rhino 6.x-1 … 6.x-n.

Hope this helps.

– Dale

3

Thank you Dale, that makes the version scheme w.r.t. the plugins and the program clear.

However, regarding code compatibility, are there any compatibility guarantees?

More specifically, we tried to compile our plugin code base using version 6.9 of the SDK (we were previously using version 6.3). This resulted in several deprecation errors because of the CRhinoDoc::BoundingBox() function, which now requires 3 explicit arguments (i.e. they don’t provide any default values any longer).
Is this expected, that deprecated functions now fail with an error? Shouldn’t this be a warning?
And regarding this function? What would be good values to pass to the function? I’m now passing (false, true, true). However, I’m not 100% sure whether those are the correct values to pass (previously, we called the function without any parameters).

Kind regards,
Erik

4

Hi @e.valkering,

I’m not sure what this means. We try our best not to break compatibility with existing plug-in.

You can turn off the warning for a specific line of code by using the warning pragma, #pragma warning(suppress : 4996).

You can also turn the warning off within a file by using the warning pragma, #pragma warning(disable : 4996).

You can turn the warning off globally in command line builds by using the /wd4996 command line option.

https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-3-c4996?view=vs-2017

– Dale

5

Thanks, Dale.

However, I prefer not to suppress this warning. I presume this function will be removed eventually, so it’s best to fix is right away.

Would you have any suggestions on what to pass to the recommended 3-argument alternative?

6

Here is the definition of CRhinoDoc::BoundingBox():

const ON_BoundingBox& CRhinoDoc::BoundingBox(bool bIncludeCustomRenderMeshes) const
{
  return BoundingBox(false, bIncludeCustomRenderMeshes, true);
}

Perhaps this helps?

– Dale

7

Great, that was exactly what I guessed.

Thanks!

8

I am assuming this is the same for Rhino 7. Specifically, a plug-in built with the Rhino 7 C++ SDK will NOT load and run in Rhino 6?

I know it is forward compatible, so a plug-in built with the Rhino 6 C++ SDK WILL load and run in Rhino 7. Although at some point, through SDK changes/usage, my plug-in will eventually fail the Installer Engine’s “compatibility check.” So I’m assuming it would be better to build separate RHPs, one for each major version, using the appropriate SDKs. Is that correct?

Sorry for piggybacking on an older thread, but it does seem relevant since Rhino 7 was released.

9

Hi @mike14,

This is correct.

– Dale