Hello,
We have recently experienced an issue with some users getting new Service Releases and others are not. This is creating an incompatibility issue with newly built plugins that happen to be using the newer Rhino 6 and SDK that does not appear to be available to other users.
User/Dev 1 is showing “6.4.18124.12321, 5/4/2018” and is showing “Up to date” User/Dev 2 is showing “6.4.18130.19341, 5/10/2018” and is showing “Up to date”
The issue is that if User 2 develops a plugin for User 1, User 1 receives a message that they need a newer Rhino SDK.
We could change our dev process to use past NuGet package builds, but I find it odd that some users are not automatically getting SR updates pushed to their machine while others are and both are showing “Up to date”. Is there a reason for this?
Hey Nate,
There is probably a timing issue where User/Dev1 will see a new service release available in day or two.
Unless you are using new features in RhinoCommon that just showed up in the very latest service release, there shouldn’t really be a problem. Rhino 6 will load plug-ins compiled against versions of RhinoCommon newer than the end user’s version if all of the functions that the plug-in uses in the SDK exist. This is part of our compatibility testing framework. If you are seeing otherwise, let me know and we’ll see if there is a bug that we need to fix.
Hi Steve,
For example, this is an error someone received recently regarding a Gh plugin. I do not believe we are using anything newer in the latest SR that should trigger this message on the older SR although I will scrub through to make sure.
The machine that the .gha was developed on has 6.14
The machine it needs to be used on has 6.13
I know it’s best practice to keep the software up to date but this incompatibility becomes a nuisance to distributing a .gha within my company. Some people has the false belief that what is working now may be broken with an update so they turn away if an update is imperative…can we maybe reduce the frequency of the SDK update?
