Re: API deprecation / GPIO patch


Nashif, Anas
 

My view on the subject and I think we need this resolved ASAP:

Keeping APIs stable is crucial, the question is, how do we get to stable APIs and how do we maintain progress while keeping those stable. 1.0 was released as the first publicly available version of Zephyr with APIs that have been introduced without any public scrutiny and with a limited set of usage scenarios, given the plans for the project to move to a less frequent release cycle (every 3 months) and the intention to maintain a long term support branch later on and in a less frequent manner I think our true target for a stable API would but such a release and not the initial 1.0.

Having said that and going forward we need to establish a strong process for defining and changing APIs to avoid such deadlocks and the introduction of compatibility layers that would increase complexity of code and increase code size as well in some cases.

Any disagreements here? If none, I propose to accept those changes proposed by Tomasz and set a target and a plan for API stability in the project TSC.

Regards,
Anas

On 20 Apr 2016, at 05:08, Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com> wrote:

Guys,

Thoughts or answers on that one:


Question: are we comfortable with preserving app compatibility, but breaking driver compatibility? I am not so sure about this but would like some feedback from the larger group.
Tomasz

Join devel@lists.zephyrproject.org to automatically receive all group messages.