Merge lp://staging/~kgunn72/unity-mir/um-mir-0.1.8 into lp://staging/unity-mir

FAILED: Continuous integration, rev:205
http://jenkins.qa.ubuntu.com/job/unity-mir-ci/298/
Executed test runs:
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-mir-trusty-amd64-ci/161/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-mir-trusty-armhf-ci/162/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-mir-trusty-i386-ci/161/console

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/unity-mir-ci/298/rebuild

Why do we need changes like that? Did API change?

FWIW, 0.1.8 >= 0.1.7 already, and this change only adds confusion, as unity-mir happily works against both 0.1.7 and 0.1.8, AFAICT. While building the package, dpkg will mark the runtime dependency between unity-mir and mir to the actual binary version of the mir it built against, and that system should be enough. We should only bump the mir requirement when there's actual code changes needed in unity-mir that would be incompatible with earlier mir.

> Why do we need changes like that? Did API change?
>
> FWIW, 0.1.8 >= 0.1.7 already, and this change only adds confusion, as unity-
> mir happily works against both 0.1.7 and 0.1.8, AFAICT. While building the
> package, dpkg will mark the runtime dependency between unity-mir and mir to
> the actual binary version of the mir it built against, and that system should
> be enough. We should only bump the mir requirement when there's actual code
> changes needed in unity-mir that would be incompatible with earlier mir.

you are right, it isn't technically needed. this only became the way-of-doing in order to have a rebuild forced, back in the old days. but now with ci train, you are right we should be able to have an empty commit rebuild since its in our control.
I'm going to start trying the empty commit method. I'll just double check with the release team in case there was some other non-obvious reason we were bumping.