Alaska Software Inc. - Xbase++ DLL and Xbase++ BUILD Level ?
Username: Password:
AuthorTopic: Xbase++ DLL and Xbase++ BUILD Level ?
Hubert BrandelXbase++ 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. PirsigRe: 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.