On Tue, Mar 14, 2017 at 4:02 PM, Honnappa Nagarahalli < [email protected]> wrote:
> On 14 March 2017 at 14:41, Dmitry Eremin-Solenikov > <[email protected]> wrote: > > Hi, > > > > On 14.03.2017 07:06, Honnappa Nagarahalli wrote: > >> 2) What is the purpose of the deprecated API flag? > > > > It's purpose is to allow applications to recognize that the API is going > > to be removed in the next release and thus to migrate from old API to > > new replacement. > > Will we use ODP_DEPRECATED macro to indicate the API is deprecated? If > yes, the compiler will generate the warning if the application uses > the deprecated API. Why do we need a new flag? > > Do you know what is ODP's policy on deprecation? You have mentioned > 'next release', do you know what it means? Major release, minor > release? > Petri indicated he will be reposting his patch to incorporate some of the points raised by Dmitry as well as others on Monday. The issue is how to handle deprecations when ABI compatibility is in play. There is general agreement on the following points: - Deprecations will be rare and only for good cause - We don't want to support "hybrid" cases where applications are free to mix old and new APIs and expect everything to work. You're either using an old API or it's successor. - When replacement APIs are introduced all ODP samples and examples will be updated to use the new APIs. - Any deprecations will be documented and will allow adequate time for applications to migrate. What's new in the discussion is the agreement that if any fields in a struct are deprecated they will be replaced with renamed fields to retain ABI compatibility (e.g., __odp_deprecated_fieldname) rather than be deleted. Compacting structs will only occur on tagged release boundaries that are designated as ABI boundaries (i.e., releases that require application recompile). > > > > > -- > > With best wishes > > Dmitry >
