In 17.2, the signatures were in the form:
Code: Select all
long Long (string myString)
Code: Select all
long Long (string myString, bool hasExceptions = true)
Code: Select all
Method not found: Int64 OpenDentBusiness.Pin.Long(System.String)
Code: Select all
long Long (string myString)
Code: Select all
long Long (string myString, bool hasExceptions = true)
Code: Select all
Method not found: Int64 OpenDentBusiness.Pin.Long(System.String)
We don't have an API and have zero backwards compatibility guarantees for all code available. Those functions are absolutely available for use and I encourage you to continue to use them. It would be nice to enhance our plug-in framework with a marketplace and make an official API and make a everything backwards compatible with legacy libraries, etc, etc. There just isn't time to do all of that right now.tim wrote:What are the API compatibility guarantees for the OpenDentBusiness DLL? Or should we not have been using these functions from the beginning?
Is it unreasonable to add those original method signatures back to OpenDentBusiness.PIn (possibly including them in a 17.3 patch), and then add a new method overload that adds the hasExceptions parameter?jsalmon wrote:We don't have an API and have zero backwards compatibility guarantees for all code available. Those functions are absolutely available for use and I encourage you to continue to use them. It would be nice to enhance our plug-in framework with a marketplace and make an official API and make a everything backwards compatible with legacy libraries, etc, etc. There just isn't time to do all of that right now.tim wrote:What are the API compatibility guarantees for the OpenDentBusiness DLL? Or should we not have been using these functions from the beginning?
It is unreasonable to add overloads to all the methods that we broke with optional parameters. We now enter the classic "if you bring candy, make sure you bring enough for the entire class". That's why it would be nice if we had some sort of backwards compatibility guarantee like you mentioned earlier but we don't ATM.tim wrote:Is it unreasonable to add those original method signatures back to OpenDentBusiness.PIn (possibly including them in a 17.3 patch), and then add a new method overload that adds the hasExceptions parameter?
Is it suggested that we should pin our plug-in DLLs with specific Open Dental releases, and prevent them to run due to potential runtime failures due to missing methods?jsalmon wrote:It is unreasonable to add overloads to all the methods that we broke with optional parameters. We now enter the classic "if you bring candy, make sure you bring enough for the entire class". That's why it would be nice if we had some sort of backwards compatibility guarantee like you mentioned earlier but we don't ATM.tim wrote:Is it unreasonable to add those original method signatures back to OpenDentBusiness.PIn (possibly including them in a 17.3 patch), and then add a new method overload that adds the hasExceptions parameter?
Open Dental doesn't really have a suggestion one way or the other that I'm aware of. Right now Open Dental just supplies the source code and says "good luck" to everyone else. Your suggestion is one way to approach it and would probably give the users of your plug-in a better experience unless you had a hard time keeping up with our version releases.tim wrote:Is it suggested that we should pin our plug-in DLLs with specific Open Dental releases, and prevent them to run due to potential runtime failures due to missing methods?
Alright, thanks for all the details, Jason!jsalmon wrote: Open Dental doesn't really have a suggestion one way or the other that I'm aware of. Right now Open Dental just supplies the source code and says "good luck" to everyone else. Your suggestion is one way to approach it and would probably give the users of your plug-in a better experience unless you had a hard time keeping up with our version releases.