Mir Version 1, stable ABIs and licences

[Alan Griffiths]

On 13/10/16 02:59, Daniel van Vugt wrote:
> My personal view is that we should drop this discussion.

I disagree. The team is meeting IRL next week and should further discuss
these issues. Without the current discussion, however, we would not be
prepared.

>
> We have been mindful of reducing ABI breaks for years but that gets
> trumped by the need to implement missing features etc.

There is nothing inherent in adding features that requires ABI breaks,
it is simply a design trade-off. We have made different choices for
different ABIs - the client ABI has not broken for ten releases now. The
server ABI has only *not* broken for one release.

We now have a likely consensus on an approach for stabilizing the server
ABI. Vis: recommend using libmiral for shell development and keep
libmiral and libmircore ABI stable.

> Mir code landings have been extremely active recently, with thousands
> of lines changing every day or so. And to me that's the opposite of
> what would be happening near a maturation milestone.

A lot of this churn is around the graphics and input stacks, which I
agree are not yet mature enough to commit to fixing the APIs we have
right now. But it is extremely important to consider what is needed to
achieve stability,

My personal view is that we now have enough "stacks" working (at least
experimentally) to refine the useful abstractions. That will take some
time, but it is important to call out the need for this and to
prioritise the effort.

> I think we should let maturation happen organically. When the changes
> slow down and when we actually haven't broken ABIs for a while, that
> would be the right time to have this discussion.

I disagree. We must make it a goal, assess progress towards it, and plan
activities to support it. Otherwise it will not happen!