<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jul 31, 2015 at 8:56 AM, Michael Zanetti <span dir="ltr"><<a href="mailto:michael.zanetti@canonical.com" target="_blank">michael.zanetti@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 30.07.2015 23:34, Martin Albisetti wrote:<br>
><br>
> On Jul 30, 2015 5:35 PM, "Alberto Mardegan"<br>
</span>> <<a href="mailto:alberto.mardegan@canonical.com">alberto.mardegan@canonical.com</a> <mailto:<a href="mailto:alberto.mardegan@canonical.com">alberto.mardegan@canonical.com</a>>><br>
<span class="">> wrote:<br>
>><br>
>> On 07/30/2015 11:09 PM, Martin Albisetti wrote:<br>
>> > I'm assuming this changes needs to be paired with:<br>
>> ><br>
>> > - Dropping all frameworks as supported from that image once this lands<br>
>> > - Introducing a new framework<br>
>><br>
>> Is (or will it be) possible to upload to the store more than one version<br>
>> of one app, if these versions require different frameworks?<br>
>><br>
>> If so, the transition wouldn't be as painful for app developers.<br>
><br>
> That isn't planned, no. The main reason being we said we would keep<br>
> backwards compatibility aggressively, and we would keep our phone user<br>
> base on the same, updated OS version to avoid fragmentation.<br>
> This GCC change seems to break on that, I was surprised by it, but maybe<br>
> there's a plan on how to keep backwards compatibility instead?<br>
><br>
<br>
</span>Just as a feedback, due to a recent incompatibility between OTA-4 and<br>
OTA-5 apps I noticed that there is some notable number of people that do<br>
not regularly upgrade their phones.<br>
<br>
Even if we think that would be the way to go. IMO we cannot expect<br>
everybody to upgrade all the time. The current solution with not<br>
allowing to publish the same app for multiple frameworks will cause:<br>
<br>
* frustrated users because apps just break or disappear for them<br>
* developers publishing the same app multiple times with different<br>
appid's just to work around your decision. This in turn will lead to<br>
more frustrated users because the "same" app will lose all the settings<br>
and caches on system apgrades.<br>
<br>
<br>
Both of them are already happening. Imagine how this will get even worse<br>
when at some point the the hardware we sold won't actually support a new<br>
upgrade any more.<br></blockquote><div><br></div><div>we won't let that happen, I think we owe it specifically to our early supporters to provide them with continued support over a reasonable HW life time. </div><div><br></div><div>The OTA-4/OTA-5 incompatibility seems more like a bug than an architectural / platform issue (i.e. not comparable to gcc5) and wasn't a conscious decision we took.</div><div><br></div><div>We are facing the interesting problem of shipping a stable product to customers, iterating that product platform quite rapidly and then also basing this work of the distribution and its ecosystem, which is moving at an entirely different speed.</div><div><br></div><div>Instead of blocking the Ubuntu-sphere from moving to gcc5 at a time that is right, we are accepting that the phone devel-proposed is seeing  transition issues, while keeping our shipping code base stable.  </div><div><br></div><div>As Pat mentioned in his initial mail, we are working on unblocking things asap, but the solution needs to be well crafted and thus might take a bit before we are ready. It's in our own interest to unblock testing of devel-proposed to keep in sync with the "upstream" development.</div><div><br></div><div>cheers,</div><div>Olli</div><div><br></div></div></div></div>