So it looks like we missed versioning some symbols correctly in trunk/devel (like mir_connection_create_spec_for_input_method, mir_connection_create_spec_for_modal_dialog) for example
So we should at least keep those in their respective stanzas.
Regarding exposing C++ symbols and implementation details - that is a pre-existing issue so I would consider that outside the scope of this MP.
@Chris:
>I don't think this is the right way to fix the bug, but I don't particularly feel like fixing >it the right way myself at the moment
Why not? The alternative I see is replicating symbols by wrapping them in the client and versioning them under a MIR_CLIENT_8.x stanza. I guess the advantage there is server code or other places that need them can just link to libmircommon instead of libmirclient.
So it looks like we missed versioning some symbols correctly in trunk/devel (like mir_connection_ create_ spec_for_ input_method, mir_connection_ create_ spec_for_ modal_dialog) for example
http:// pastebin. ubuntu. com/10621901/
However it does look like the functions mentioned in the versioned stanzas are indeed versioned correctly: pastebin. ubuntu. com/10622070/ pastebin. ubuntu. com/10622077/ pastebin. ubuntu. com/10622081/
http://
http://
http://
So we should at least keep those in their respective stanzas.
Regarding exposing C++ symbols and implementation details - that is a pre-existing issue so I would consider that outside the scope of this MP.
@Chris:
>I don't think this is the right way to fix the bug, but I don't particularly feel like fixing >it the right way myself at the moment
Why not? The alternative I see is replicating symbols by wrapping them in the client and versioning them under a MIR_CLIENT_8.x stanza. I guess the advantage there is server code or other places that need them can just link to libmircommon instead of libmirclient.