ubuntu-phone team mailing list archive

[Tim Peeters <tim.peeters@xxxxxxxxxxxxx>]

Hello,

Just to make sure everything is clear, this is the proposal:

- The Page.head property will *NOT* be touched. It will stay as deprecated
(as it was) and no Page API will change.
- From OTA13, the deprecated Page.head (and also Page.title) property will
be ignored *only* if it is used inside APL. That means, if your Page needs
a header and it is inside an APL, use the new Page.header.
- From OTA12, we will give the deprecated header inside the APL a red
outline, as a final warning for apps that are mixing APL with the
deprecated Page.head.
- If you are not using APL, the deprecated header will keep working as it
was. But we still urge you to switch to the new PageHeader as is explained
on https://developer.ubuntu.com/en/blog/2016/02/24/pageheader-tutorial/

The reason for this change is that we need to optimize APL to be faster,
and for that we need to move its implementation to C++ without support for
the deprecated header API.


The reasons that we do this in 1.3 and not introduce 1.4 right now are the
following:
- Having 1.4 would not solve the problem. APL is not performing good enough
now, so you have to switch to 1.4 anyway.
- UITK 1.3 is not feature complete yet (but we are getting close).
- Introducing a new version will require us to duplicate the qml files for
the components and themes, duplicate all the tests, and add an otherwise
useless property to StyledItem to detect the correct version of the theme.
- Updating the apps to 1.4 will be a lot of work but necessary if the apps
want to use the convergence features.

Because of all this, we better finish UITK 1.3 and then declare it as
frozen and support it for a long time.

Greets,
Tim.


On Fri, May 20, 2016 at 12:14 PM, Tim Peeters <tim.peeters@xxxxxxxxxxxxx>
wrote:

> Hello Alberto
>
> On Fri, May 20, 2016 at 11:29 AM, Alberto Mardegan <
> alberto.mardegan@xxxxxxxxxxxxx> wrote:
>
>> Hi Zsombor,
>>
>> On 20/05/2016 08:33, Zsombor Egri wrote:
>> [...]
>> > Second, frameworks do guard you from API breaks, indeed. What I am
>> > surprised a bit is you guys immediately thought this change will be an
>> > API break. Which is not. Again, this wasn't clear from the original
>> > mail.
>> [...]
>>
>> You yourself wrote this just a couple of messages above:
>>
>> "apps made prior to 15.04.5 (or wherever this change will land) will
>> stop working with pages using old header configuration setup. So if you
>> have apps in the store which uses APL with old page header
>> configurations, please update those."
>>
>> Whether this is an API break or behavioural break or anything else, what
>> ultimately matters to developers is: does my app require changes?
>> I still haven't understood the answer to that (call me "slow" :-) ).
>>
>
> Yes, if your app uses APL but the old deprecated header, the app will need
> to be updated. That's why I sent out the reminder.
>
>
>>
>> [...]
>> > Third: we do not have the labs module, therefore we are releasing
>> > components straight to the final module. But, we never said that 1.3 is
>> > feature complete, frozen. We said the API is released, and we stick to
>> > it, but as long as it is not frozen, we may and most probably will
>> > change behavior as the planned feature set requires us to do that. Once
>> > the component set gets frozen, we will open the next version and will
>> > work on that.
>> [...]
>>
>> Unless I misunderstood you again, this is a terrible way of delivering
>> an SDK.
>> Developers must be told: the current stable release is X.Y. The stable
>> release can receive only bugfixes, which in no way can break the API or
>> cause behavioural changes (other than the matter of the bugfix, of
>> course).
>> If UITK 1.3 does not satisfy these requirements, developers must be told
>> to use 1.2, and all the documentation and QtCreator templates must be
>> changed to recommend using 1.2.
>>
>
> The stable release is 1.2, which does not break API or behavior.
>
> UITK 1.3 is still under development, but if you need the convergence
> features or new designs, that is the one you need to use. We will release
> 1.3 as stable once those features are there, tested and with high
> performance.
>
>
>> Once an app has been published to the store it should always continue
>> working unmodified, until the framework is retired.
>>
>
> If we only ask people to use 1.3 only after it is marked as stable, we
> would have to mark it stable without having a lot of testing of actual apps
> with it, so I do not think that is a good idea. Also apps need components
> like APL now, and we cannot let them wait until all the features for
> convergence are 100% ready (and tested in actual apps) before they are
> allowed to use 1.3.
>
> Greets,
> Tim.
>
>
>>
>> Ciao,
>>   Alberto
>>
>> --
>> Mailing list: https://launchpad.net/~ubuntu-phone
>> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~ubuntu-phone
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>