On 2 May 2017 at 23:48, Dmitry Eremin-Solenikov
<dmitry.ereminsoleni...@linaro.org> wrote:
> On 03.05.2017 07:43, Honnappa Nagarahalli wrote:
>> Let us say:
>>
>> API spec v1.20 could define:
>>
>> typedef struct odp_foo_bar_t {
>> /** This is foo*/
>> uint8_t foo;
>> } odp_foo_bar_t;
>>
>>
>> API spec v1.30 could define:
>>
>> typedef struct odp_foo_bar_t {
>> /** @deprecated Foo is deprecated, use bar instead. */
>> uint8_t foo;
>>
>> /** This is bar */
>> uint8_t bar;
>> } odp_foo_bar_t;
>>
>> Application (with out any changes) moves to v1.30, it still compiles and
>> runs.
>>
>> Application writer checks what is deprecated by searching for
>> '@deprecated' or looking at the release notes and changes his code for
>> v1.30.
>
> This does not work. Nobody reads release notes in check for deprecated
> API until his piece of software breaks horribly. Even we do not do that,
> as demonstrated by Petri's patch 3/4.
If I am the manager who takes the decision to move to next release, I
would first read the release notes to see what changed in the release
(did someone make a bogus release?), I would look at the performance
benchmarking report to see how this release affects the performance.
This will save a ton of money and effort for the company and the team.
This also needs to be done to understand how much effort (not just
changing the code, testing in QA, support etc) is required and how
much it will cost vs the benefits of moving to this release.
If somebody wants to get a feel for the benefits, the code still
compiles in the approach I have described.
> --
> With best wishes
> Dmitry
