From the decorations (and names) it looks these symbols are all OpenAL
extensions...except for alBufferAppendData, which appears to have been
(incorrectly?!?) exported as a non-decorated symbol too. One document
from 2001 referes to the "well-documented" alBufferAppendData, but it's
not in the 1.1 spec, not even as a dropped symbol.
Anyway, I can't deny that, to the extent that there might be an
(undocumented and now deprecated?) core function in OpenAL, that that
would warrant a .so version name change.
I don't think the other symbols with decoration should warrant a soname
change; like OpenGL, OpenAL extension discovery should be done at
runtime to cope with renderers that don't provide all extensions;
changing the major version because a particular extension was dropped
would punish apps that correctly check extensions at runtime.
Ah - thank you for the symbol list!
From the decorations (and names) it looks these symbols are all OpenAL
extensions...except for alBufferAppendData, which appears to have been
(incorrectly?!?) exported as a non-decorated symbol too. One document
from 2001 referes to the "well-documented" alBufferAppendData, but it's
not in the 1.1 spec, not even as a dropped symbol.
Anyway, I can't deny that, to the extent that there might be an
(undocumented and now deprecated?) core function in OpenAL, that that
would warrant a .so version name change.
I don't think the other symbols with decoration should warrant a soname
change; like OpenGL, OpenAL extension discovery should be done at
runtime to cope with renderers that don't provide all extensions;
changing the major version because a particular extension was dropped
would punish apps that correctly check extensions at runtime.
cheers
Ben
-- scenery. x-plane. com/ xplanescenery. blogspot. com/ www.xsquawkbox. net/xpsdk/ wiki.x- plane.com/
Scenery Home Page: http://
Scenery blog: http://
Plugin SDK: http://
X-Plane Wiki: http://
Scenery mailing list: <email address hidden>
Developer mailing list: <email address hidden>