On Wed, Apr 12, 2017 at 10:05 AM, Dmitry Eremin-Solenikov <[email protected]> wrote: > On 12.04.2017 17:24, Bill Fischofer wrote: >> On Wed, Apr 12, 2017 at 8:22 AM, Dmitry Eremin-Solenikov >> <[email protected]> wrote: >>> On 12.04.2017 15:21, Bill Fischofer wrote: >>>> On Wed, Apr 12, 2017 at 7:11 AM, Dmitry Eremin-Solenikov >>>> <[email protected]> wrote: >>>>> On 12.04.2017 14:50, Savolainen, Petri (Nokia - FI/Espoo) wrote: >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Dmitry Eremin-Solenikov [mailto:[email protected]] >>>>>>> Sent: Wednesday, April 12, 2017 2:32 PM >>>>>>> To: Petri Savolainen <[email protected]>; lng- >>>>>>> [email protected] >>>>>>> Subject: Re: [lng-odp] [API-NEXT PATCH v2 0/4] Deprecated macros >>>>>>> >>>>>>> On 30.03.2017 16:58, Petri Savolainen wrote: >>>>>>>> Replaced ODP_DEPRECATED macro (which was based on GCC __attribute__) >>>>>>> with >>>>>>>> compiler independent mechanism to control if deprecated API definitions >>>>>>> are >>>>>>>> visible to the application. ODP_DEPRECATED_API can be used both in >>>>>>> application >>>>>>>> and implementation to check if deprecated APIs are enabled. By default >>>>>>> those are >>>>>>>> disabled. Implementation may optimize the normal (new API) code path. >>>>>>>> >>>>>>>> ODP_DEPRECATE() macro is used to rename definitions, so that data >>>>>>> structure >>>>>>>> sizes are equal on both options. This enables implementation to serve >>>>>>> both >>>>>>>> options with a single library (if it wishes to do so). >>>>>>> >>>>>>> My main question remains as it was before: is it possible for the >>>>>>> distribution to supply (unoptimized) ODP binary and headers and then for >>>>>>> the application to select if it builds with or without deprecated API >>>>>>> using that binary/headers? >>>>>> >>>>>> >>>>>> Yes. This patch set keeps the same struct fields/etc for both modes - >>>>>> only the names are scrambled (with __deprecated_ prefix) when deprecated >>>>>> APIs are not supported (the default). >>>>> >>>>> If so. Consider I have built and installed ODP headers & binary built >>>>> with --enable-deprecated-api. >>>>> >>>>> How do I build: >>>>> >>>>> - application that uses deprecated API? >>>>> [I assume that the answer to this question is trivial: just build as >>>>> is]. >>>>> >>>>> - application that wants to be sure that it does not use deprecated API? >>>> >>>> As a practical matter, the support of deprecated APIs is similar to >>>> the current provision for debug builds (--enable-debug and >>>> --enable-debug-print in the current ./configure script). These really >>>> are only of significance in the embedded space. >>> >>> Or for application developers. >>> >>>> In the cloud profile, >>>> applications use whatever ODP release(s) are installed on the system >>>> and the normal library-matchings are used to ensure that applications >>>> built for Release X are paired with library .so files compatible with >>>> that release. In this case, there are no deprecated APIs since >>>> applications only move to newer ODP release levels when they are >>>> ready. A cloud host system may specify the minimum ODP release level >>>> available on it, and that determines when laggards need to upgrade. >>> >>> Yep. That is the deployed ODP release. It is optimized for speed, it is >>> optimized for that exact platform, etc. I'm more thinking about app >>> developers. >>> >>>> >>>> So ODP will never ship a distribution that was configured with >>>> --enable-deprecated-api. The only users of this feature will be >>>> embedded applications that are customizing ODP to their own needs. >>> >>> I'm thinking about SuSe, Canonical, RedHat or anybody else shipping ODP >>> to enable application development on that platform. They would surely >>> want to enable deprecated API (because otherwise old applications >>> developed on that platform can stop building). But I'd expect that it is >>> possible for the application developer to build an application checking >>> that he does not use deprecated API anymore. >> >> This is really no different than supporting multiple levels of, say, >> the GCC compiler. Or any other package. At some point the old releases >> are no longer supported, but for some time you can have multiple >> levels available at the same time and you just use the one that you >> need. > > We might want to consult maintainers. But from my previous experience, > supporting several 'levels' is a significant headache, that most of > maintainers would like to stand away from. Moreover, even if several > versions are provided by distro, app developers still would like to have > 'migration' path. Consider the way deprecated API are implemented e.g. > in Gtk, Qt or other app frameworks.
The migration path is very straightforward: Don't move until you're ready to move. When you are ready to move you change your application to use the new preferred APIs. Will some wait until they are forced to move because the older releases are no longer distributed? Sure. But that's just business as usual. The point is that distributions can choose to distribute whatever level(s) of ODP they wish. Our biggest problem is more likely to be not that they won't distribute older releases but the lag in getting them to distribute newer releases. It also points out that we really shouldn't be deprecating APIs in the first place. These should be very rare instances, not something so commonplace that we need a general framework to make it convenient to deprecate a bunch of stuff each release. An API is "forever" and we need to be mindful of that when we pour the concrete. As a practical matter, the main reason for deprecating an API is because it is superseded by a better way to do something. But keeping the older API around just means that applications don't get the advantage of using the newer way until such time as we get tired of carrying around the old baggage and the old forms get removed. So deprecation is more a documentation than a code issue, which is all that the original ODP_DEPRECATED() macros were intended to do. A likely more controversial issue is that we've stated that ODP makes no ABI compatibility claims from one release to the next. It's assumed that applications will recompile to move from ODP Release N to ODP Release N+1. In ODP, ABI compatibility is a statement of compatibility across different ODP implementations of a given API release, not across multiple API releases. > > -- > With best wishes > Dmitry
