ubuntu-phone team mailing list archive

[Alexander Sack <asac@xxxxxxxxxxxxx>]

On Thu, Jan 23, 2014 at 7:38 PM, Alejandro J. Cura
<alejandro.cura@xxxxxxxxxxxxx> wrote:
> On Thu, Jan 23, 2014 at 3:35 PM, Alejandro J. Cura
> <alejandro.cura@xxxxxxxxxxxxx> wrote:
>> On Thu, Jan 23, 2014 at 11:34 AM, Jamie Strandboge <jamie@xxxxxxxxxxxxx> wrote:
>>> I think this a great approach. Like Alexander and I have mentioned, something
>>> like this could get messy quickly ('"framework": "ubuntu-14.04 -
>>> ubuntu-14.04.3"' seems potentially ok, but '"framework": "ubuntu-14.04 -
>>> ubuntu-16.04"' does not).
>>
>> I assume point releases in frameworks should be forward compatible.
>>
>> So, I don't see a reason to specify something like "ubuntu-14.04 -
>> ubuntu-14.04.3". If the app has no need for APIs added to 14.04.3, it
>> should specify "ubuntu-14.04", and our tools should understand that it
>> will still work on 14.04.3.
>
> Furthermore, having closed ranges like that will force all devs to
> re-upload their apps on every point update of the frameworks. And that
> sounds awful.

I think for most cases just the minimum version of a major framework
series is indeed enough.

However, I see a few cases where range type of compatibilty can be valid/handy:

 1. to incubate our "next" framework during development we need
clients/apps in the image/store, for that apps probably should be able
to say "i need exactly 14.04~beta1"
 2. very basic apps that only use very mature parts of our APIs might
be lucky and can continue working across major framework versions
(e.g. 14.04 - 14.10)
 3. Also, in practice we might accidentally break apps within a major
framework, having a range would allow app devs to ship a quick
disable/fix while they investigate and prepare the real fix.


Cheers,

 - Alexander