← Back to team overview

ubuntu-phone team mailing list archive

Re: What moving to GCC5 means for the phone and app developers

 


On 30.07.2015 23:34, Martin Albisetti wrote:
> 
> On Jul 30, 2015 5:35 PM, "Alberto Mardegan"
> <alberto.mardegan@xxxxxxxxxxxxx <mailto:alberto.mardegan@xxxxxxxxxxxxx>>
> wrote:
>>
>> On 07/30/2015 11:09 PM, Martin Albisetti wrote:
>> > I'm assuming this changes needs to be paired with:
>> >
>> > - Dropping all frameworks as supported from that image once this lands
>> > - Introducing a new framework
>>
>> Is (or will it be) possible to upload to the store more than one version
>> of one app, if these versions require different frameworks?
>>
>> If so, the transition wouldn't be as painful for app developers.
> 
> That isn't planned, no. The main reason being we said we would keep
> backwards compatibility aggressively, and we would keep our phone user
> base on the same, updated OS version to avoid fragmentation.
> This GCC change seems to break on that, I was surprised by it, but maybe
> there's a plan on how to keep backwards compatibility instead?
> 

Just as a feedback, due to a recent incompatibility between OTA-4 and
OTA-5 apps I noticed that there is some notable number of people that do
not regularly upgrade their phones.

Even if we think that would be the way to go. IMO we cannot expect
everybody to upgrade all the time. The current solution with not
allowing to publish the same app for multiple frameworks will cause:

* frustrated users because apps just break or disappear for them
* developers publishing the same app multiple times with different
appid's just to work around your decision. This in turn will lead to
more frustrated users because the "same" app will lose all the settings
and caches on system apgrades.


Both of them are already happening. Imagine how this will get even worse
when at some point the the hardware we sold won't actually support a new
upgrade any more.

IMO this decision needs to be revised.

Br,
Michael

Attachment: signature.asc
Description: OpenPGP digital signature


Follow ups

References