ubuntu-phone team mailing list archive

[Zsombor Egri <zsombor.egri@xxxxxxxxxxxxx>]

Gentlemen,

First of all apologies for the first email, it did not contain a valuable
information which was that we were planning to introduce this "break" by
the end of summer. So not like tomorrow, not next week, not next OTA
release. Because we haven't even started the work. All we did is we checked
the possibility to move the implementation to C++ so we can gain speed on
its initialization and we can get rid of some intermediate code we had to
do in order to have multi-column support, which is lot easier/faster in
C++, and the conclusion was that, in order to be able to fully do it in
C++, we need to drop support for Pages which have the old header in use.
That's why Tim (Peeters) sent out the email about this intention, which was
slightly miscommunicated, and resulted in your anger. The announcement was
supposed to give you time to update your apps w=before we do the changes.

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. The
word "drop" or "change" can indeed easily be misunderstood and associated
with breaking APIs, apps getting broken, etc. This action would not involve
any API breaks. AdaptivePageLayout (APL) has no API for page header
management, and Page has both old and new header management APIs there,
right? Also, APL is a 1.3 component and it is meant to support 1.3
components. We had to have support for the old header as we had to release
it earlier we have the new PageHeader in place, and therefore we had the
old header support added. Also, it has been released in QML as that allowed
us to release you the component so you can adapt and comment on the API. So
we are trying to remove this dependency so we can go for an optimized
component.

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. Unfortunately we are not there yet, we have few more components to
update and to introduce, and then we can go for the next version, which btw
may be 2.0, but perhaps 1.4... 1.3 was released as stable API, not as
frozen module, which if it would, we would have been at 1.4 or perhaps 1.5
already.

And yes, a blogpost explaining on what exactly you should do would have
been the next step to do after the email is out. But perhaps the order
should have been vice versa: write the post and then advertise it in all
the channels. I'm sure Tim (P) will do one, but I can spoil you :) All you
would need is to "prepare" your app for 1.3 use. So if your pages added to
APL were using Page.head to configure the header, and set the title using
the Page.title property (which also got deprecated btw), all you need to do
is to move all that under Page.header: PageHeader {...} setup. There are
already few things which do not work with the old page header when used in
APL, like the header is always locked and cannot be scrolled out, and you
would need the new header to do that. So I think you guys already did this
migration, and won't affect you at all. This mail is not more than making
sure you really did that, and iinm we already discussed about this and gave
even a tutorial as Tim (P) posted.

So, again, no API break, all we're asking you to check your apps and if you
are using Page.head in pages added to the APL, please move them to use
Page.header.

AdaptivePageLayout {
....
    primaryPage: Page {
        head {
        }
        title: "Page Title"
    }
}

should be transitioned into

AdaptivePageLayout {
....
    primaryPage: Page {
        header: PageHeader {
            title: "Page Title"
        }
    }
}

And last but not least, we missed some communication channels with this
message, and special thanks to those who posted the link to G+ and
Telegramm to reach those who are not following or subscribed to this ML.
Next time, hopefully, we will be better in this.

Cheers,
Zsombor


On Fri, May 20, 2016 at 3:25 AM, Nick Luigi V. Eusebio <kugi_igi@xxxxxxxxx>
wrote:

> I agree on this. Isn't it the purpuse of using frameworks/UI toolkit
> versions? I think this isn't a good practice. This has happended quite
> frequently. You can't assume that all developers are following this list.
> In the end the consumers are the one greatly impacted by this. They'll get
> broken apps from the store. Imagine Google doing something like this. Play
> Store will surely have millions of apps bot working. That could be a riot.
> Hopefully we can think of a better way pushing this kind of changes.
>
> On Friday, May 20, 2016 3:19:00 AM PHT, Tim Süberkrüb <
> tim.sueberkrueb@xxxxxx> wrote:
>
>> Hi Zsombor,
>>
>> thanks for your reply.
>>
>> I'd then like to request a better policy for such changes.
>> When I asked about click frameworks some time ago, I was told that they
>> are meant to
>> keep apps from breaking, each framework should be one fixed environment
>> the app is targeting.
>> But it looks like that's not true. I probably just didn't understand that
>> correctly.
>>
>> But if it's not the framework versions, then at least the UI Toolkit
>> version should be reliable IMO.
>> As far as I know, UUITK 1.3 was released as a stable release, wasn't it?
>> At least it's the current recommended release. Apps that target a specific
>> UITK release should not just break over time until the release is
>> officially announced as deprecated. At least that's my understanding of
>> releases and version numbers :) I really don't like being forced to update
>> my apps before I'm ready with my next release at least not because of
>> changes like this.
>>
>> Also, I'm not following this mailing list actively. If there haven't been
>> a message in the Ubuntu Apps telegram group, I would not even have realized
>> this thing. And that doesn't mean I don't care. I love Ubuntu and the
>> phone, that's why I'm writing apps for it! But I don't have unlimited time
>> to do so. It's all my free time I'm spending here.
>>
>> Have a nice evening everyone,
>> Tim
>>
>>
>> Am 19.05.2016 um 20:34 schrieb Zsombor Egri:
>>
>>> Hello Tim,
>>>
>>> As we are not making any new component, and we are targeting this work
>>> to happen with 1.3 UI Toolkit, 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.
>>>
>>> Cheers,
>>> Zsombor
>>>
>>> On Thu, May 19, 2016 at 9:17 PM, Tim Süberkrüb <tim.sueberkrueb@xxxxxx
>>> <mailto:tim.sueberkrueb@xxxxxx>> wrote:
>>>
>>>     Hey Tim,
>>>
>>>     I was wondering whether this change does affect all frameworks?
>>>
>>>     For example, will an app using the APL and targeting a prior
>>>     15.04.X framework release break because of this change or will
>>>     only 15.04.5 apps be affected?
>>>
>>>     Thanks for your reply!
>>>
>>>     All the best
>>>     Tim
>>>
>>>
>>>     Am 19.05.2016 um 16:52 schrieb Tim Peeters:
>>>
>>>>     Hello all,
>>>>
>>>>     As you probably know, some time ago we introduced the new
>>>>     PageHeader component (see
>>>>
>>>> https://developer.ubuntu.com/en/blog/2016/02/24/pageheader-tutorial/
>>>>     ). An instance of PageHeader can be assigned to Page.header to
>>>>     define the header of a Page, and if no Page.header is specified,
>>>>     there is an automatic fallback to the old header.
>>>>
>>>>     In AdaptivePageLayout (APL), there is also a fallback header in
>>>>     each column, but that complicates the APL implementation, it is
>>>>     not fully covered by tests, and does not support all the features
>>>>     of the new PageHeader, so we will drop support for that soon. We
>>>>     need to do this before we move the APL implementation to C++ (the
>>>>     API will be the same, so no more changes in app code will be
>>>>     needed for that, but the APL will be much faster), so please
>>>>     update your apps now if you are using APL but not the new
>>>> PageHeader.
>>>>
>>>>     We may update the deprecated APL column-header fallback to show a
>>>>     red border before we remove it, as a final warning. The progress
>>>>     on the removal can be followed here:
>>>>
>>>> https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1583587
>>>>
>>>>     Comments/suggestions/discussion can be added to the bug report,
>>>>     or as a reply to this e-mail.
>>>>
>>>>     Best regards,
>>>>     Tim.
>>>>
>>>>
>>>>
>>>
>>>     --
>>>     Mailing list: https://launchpad.net/~ubuntu-phone
>>>     <https://launchpad.net/%7Eubuntu-phone>
>>>     Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
>>>     <mailto:ubuntu-phone@xxxxxxxxxxxxxxxxxxx>
>>>     Unsubscribe : https://launchpad.net/~ubuntu-phone
>>>     <https://launchpad.net/%7Eubuntu-phone>
>>>     More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>>
>>
>>
>
> --
> Sent using Dekko from my Ubuntu device
>
>
> --
> 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
>