[Development] Proposal: All Qt modules must use the same version number
jocelyn.turcotte at digia.com
Thu Jul 31 12:15:55 CEST 2014
On Mon, Jun 30, 2014 at 08:58:58AM -0700, Thiago Macieira wrote:
> Em seg 30 jun 2014, às 11:10:28, Jędrzej Nowacki escreveu:
> > What about creating an intermodule api, which would stay private from a
> > user point of view. We can agree on some rules, like for example not
> > removing symbols between patch releases, having some test coverage?
> We can also call it "unsupported public API". But yes, if we do this, then
> some BC rules need to apply and we should have some minimal testing.
Following the discussion on this thread I'm trying to get rid of
QtWebEngine's dependency on qtbase and qtdeclarative private
headers/symbols, and I'm hitting one case where we might not necessarily
want the API to be public . Intermodule API doesn't have to be as
robust as public API and it would be nice to keep it that way.
Concretely, what would be the best way to define and maintain such an
In the change I'm simply marking public functions as \internal for the
documentation, but this might not be enough to discourage applications
from using it.
Another option I see is to name them _q_something as we already do for
other publically exported private functions. Or maybe somebody has other
ideas, what do you think?
More information about the Development