Author | Topic: Xbase++ DLL and Xbase++ BUILD Level ? | |
---|---|---|
Hubert Brandel | Xbase++ DLL and Xbase++ BUILD Level ? on Thu, 09 Apr 2015 09:36:16 +0200 Hi, I do use SQLexpress, XppPDF and XpZLib in some apps. With my own EXE and DLL I will recompile all with the uses Xbase++ compiler, but those external Xbase++ DLL's I just looked for the right MAIN version number 1.80, 1.82, 1.90 ... than 1.90.331 and 1.90.355 ... But now we get more Buildlevels from 2.00.xxx and I ask me if I need spezial versions of the external DLLs for every build level or just one for 2.00.x ? Regards Hubert | |
Steffen F. Pirsig | Re: Xbase++ DLL and Xbase++ BUILD Level ? on Mon, 27 Apr 2015 18:09:51 +0200 Hi Hubert, thanks for posting that question. I would like to take the opportunity the recap the Xbase++ versioning scheme and ratio - which of course will also answer your question. The Xbase++ version is constructed out of 3 numeric values. major.minor.build# First of all builds are running numbers, in fact they are incremented with each build of the full product. By definition a build# is unique but the build# has no meaning in terms of product features or product compatibility. Second, a change of the minor version number means we added a significant set of new features. Extensions of existing features or fixes/corrections are not leading to a new minor version id. They just led to a new build#. If we added a significant set of new features or fixes or changes of existing features may lead to a binary incompatibility we will increase the minor version#. This simple means your Xbase++ code needs to be re-compiled and you are all set. In terms of add-on products which have been developed using C/C++ there is no need to worry. Minor version changes do not require C/C++ add-ons to be re-compiled as we do not change the CAPI interfaces/behaviour with minor version changes. Third, changes of the major version numbers means we changed the product significantly. This means we guarantee full backward compatibility for your existing source code but your code and the code of your add ons needs to be compiled using the identical major version number. In addition C/C++ (CAPI based) add ons need to be re-compiled and the persistent data (var2Bin/bin2Var) is backward but not forward compatible. Meaning Xbase++ 1.x can not read binary data of 2.x Said that the answer to your question is, that by delivering multiple updates per year, where each of the updates has a new build# doesn't affect compatibility. In fact as long as there is no minor or major version number change you are all set. regards Steffen F. Pirsig Alaska Software Inc. |