[Development] inline namespaces as a versioning tool (was: Re: QList)

[Thiago Macieira]

On quinta-feira, 30 de março de 2017 02:40:53 PDT Marc Mutz wrote:
> Ok, not 100% transparent in all cases, then. But a symbol comparison like we
> do before a release will highlight this.

I'm assuming you're talking here about the library whose binary compatibility 
gets broken: we do a header diff, not a symbol diff. We wouldn't catch this at 
the headerdiff time because the namespace is inline, so the functions that 
were affected were not changed at all. In fact, the headers that declare those 
functions may be completely unmodified.

Aleksey does run the ABI checker tool that does show symbols. Show of hands, 
how many of you have clicked his links in the last year?

Now, if you're talking about the library that has the inline namespace, then 
yes, we'd catch it. We'd see a change in inline namespace. And our BC rules 
should require is to revert that change and keep the inline back to the 
original.

> Anyway, apart from transparency: how is that different from QFoo followed up
> by QFooV2?

Implicit (opt-out) vs explicit (opt-in). One is a silent change downstream and 
causes silent breakage unless everything gets recompiled. Even if you know 
that this is a problem and is going to happen, you can't prepare for it until 
the new class appears, so a recompilation is still needed. That's what 
happened in the std::string vs std::__cxx11::string problem.

In the other, it's explicit. Code that used to work continues to work, whether 
it's recompiled or not. There's no need to insert code to prepare for the 
update and recompile at the right time.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center