Content-type: text/html; CHARSET=US-ASCII
On Dec 05, 2012, at 12:21 PM, Tom Browder <tom.brow=
I have a user program c=
ompiled and linked against BRL-CAD v. 7.20.4
where the shared libs wer=
e v. 19. BRL-CAD v. 7.22.0 updated shared
libs to v. 20, so the progra=
m fails to link because it can't find v 19
n I assume v 20 libs are backwardly compatible with v 19?
I.e., can I =
safely do this:
I was just talking with Jim Bush about y=
ou earlier today.. So the answer is "it depends" and "probably", but=
best to just try. It will more likely give a linker failure or a cr=
ash if there's an incompatibility that affects you, not wrong answers.&nbs=
From our numbering convention, binary-incompat=
ible API changes are allowed from 7.20 to 7.22 that were announced back in=
7.18 or earlier, which is why we finally bumped the library version numbe=
r. We actually hadn't bumped it since 7.0 was released. That i=
s why you're just now seeing this.
her that really affects you or not depends on what functions you call. &nb=
sp;See the OBSOLETE and MINIMALLY IMPACTING API CHANGES sections of http:/=
for a list of changes that went into effect.
king at OBSOLETE, the only incompatible change recorded should just be a b=
u_log() change. Looking at the MINIMALLY section, there is a whole s=
lew of things that changed that would affect library runtime compatibility=
. Anything else is a mistake, bug, or documentation oversight, but I=
've been pretty good to write changes down as they occur.
For what it's worth, the intent is to allow rapid development and=
API evolution without stifling API users. Right now it's biased tow=
ards agile iterative development so we can clean out decades of cruft, whi=
ch trying to document the changes that affect external code. Is ther=
e any other API details that would help make it easier?