I meant 0.11 :-).
On Mon, Jan 26, 2015 at 2:38 PM, Cemil Azizoglu <
cemil.azizo...@canonical.com> wrote:
> FYI, we plan to land these MPs, along with mir 0.12 (expected to happen,
> later this week or early next week).
>
> -C
>
> On Mon, Jan 26, 2015 at 2:16 PM, Robert Carr
> wrote:
>
>> Hi team
On Tue, Jan 27, 2015 at 2:50 PM, Daniel van Vugt
wrote:
We seem to have some client functions residing in libmircommon now...
That sounds reasonable at first but doesn't this prevent us from
being able to bump the common ABI without breaking clients?
No? They'll just link to libmirclient8. T
On Fri, Jan 23, 2015 at 1:01 PM, Daniel van Vugt
wrote:
dandrada:
Yeah the separation of touch from mouse events doubles the number of
functions, but that's probably useful in the long run. Only dumb
legacy apps want to treat them as the same thing. Any modern app will
see them as differe
I forgot (and aren't totally sure) about indirect dependencies.
Although these client functions are obviously versioned, so even the
indirect dependencies will point to funcname@@MIR_COMMON_3.x which
sounds like it could become a problem for clients/toolkits rather
quickly as we bump the commo
On Wed, Jan 28, 2015 at 12:49 PM, Daniel van Vugt
wrote:
I forgot (and aren't totally sure) about indirect dependencies.
Although these client functions are obviously versioned, so even the
indirect dependencies will point to funcname@@MIR_COMMON_3.x which
sounds like it could become a proble
That's the point. Yes, we do now have a handful of client functions
exported from libmircommon directly to (future) clients. So that's why I
raised it...
On 28/01/15 09:55, Christopher James Halse Rogers wrote:
On Wed, Jan 28, 2015 at 12:49 PM, Daniel van Vugt
wrote:
I forgot (and aren't to
Ah, ok. That would seem to be incorrect.
On Wed, Jan 28, 2015 at 12:58 PM, Daniel van Vugt
wrote:
That's the point. Yes, we do now have a handful of client functions
exported from libmircommon directly to (future) clients. So that's
why I raised it...
On 28/01/15 09:55, Christopher James H
All,
Just a heads up... we're still seeing more regressions occurring than we
really should.
Although we can't expect authors to predict how other authors might
modify their code into the future [1], I think the common factors we can
improve on are:
* More manual testing of merge proposal