Thoughts on the limits of public headers

[Alan Griffiths]

On 30/09/14 02:42, Daniel van Vugt wrote:
> Noting that the hiding of headers in Mir 0.8, while causing some
> teething problems, has been very successful in reducing ABI bumps.
> Although we did bump ABIs in 0.8 it wasn't until late in the cycle
> that changes were committed needing any bumps. So that's a great
> improvement.

I don't think anyone is currently arguing that we should re-expose
headers without consideration. But it was done with the expectation that
headers should be re-exposed "when appropriate".

This thread is about what "when appropriate" means as there are clearly
multiple interpretations.

> I do like the idea of hiding everything till someone requests it. Our
> previous approach of trying to predict which classes people should use
> turned out to be less successful than any of us expected. Admittedly
> there's a delay there in a user requesting a header and getting a
> release with it, but the benefits are certainly worth it.

Our previous approach was not an intentional "predict which classes
people should" but a much less focussed - "if we need it in several
places then users might need it".

I don't like the idea of hiding everything that isn't in use by
Canonical's downstream projects until someone requests it. No-one that
isn't already invested in using Mir is going to expend the time needed
to know what features they want exposed and make a request.

The whole idea of Mir as a separate project (and not part of Unity8) is
that it should attract other downstream projects. That won't happen
unless we remove friction from the adoption process. If we create too
much friction they will find something that is easier to adopt.