← Back to team overview

ubuntu-phone team mailing list archive

Re: Heads up! When using AdaptivePageLayout, make sure your Page has a PageHeader.

 


On 20.05.2016 12:14, Tim Peeters wrote:
> Hello Alberto
> 
> On Fri, May 20, 2016 at 11:29 AM, Alberto Mardegan
> <alberto.mardegan@xxxxxxxxxxxxx <mailto: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.

I don't think the target should be "all features are 100%" ready. But
why not bumping the version more often and introduce some features at
any version? Noone would complain if this breakage would have happened
when changing the import from 1.3 to 1.4. Developers will have a
controlled way of upgrading then. Unlike the current situation where an
app will magically break and after fixing, it will work on stable but
not on rc-proposed or the other way round.

I see your point that it is hard to deliver new features while keeping
released apis stable. But that's really how it needs to work. There will
always be a requirement to deliver new features, that won't ever change.
We can't use that as an excuse to never have a stable API.

Br,
Michael

Attachment: signature.asc
Description: OpenPGP digital signature


References