Well, by definition, we don't need the developer to upgrade their
software. They should be able to freely use the old API with no
consequences. Thus, there is no rational reason for us to spam them.
I like the idea of the deprecated warnings, the optional flag to just
kill off deprecated functions entirely, and the optional warning.
And yes, we can keep docstrings in the deprecated header so that
people can figure out how to upgrade their calls.
Unless somebody claims this in the next day, then I'll work on this
now as a quick sidetrack of my wc work.
Cheers,
-g
On Mon, Aug 18, 2008 at 1:59 PM, Arfrever Frehtes Taifersar Arahesis
<arfrever.fta_at_gmail.com> wrote:
> 2008-08-18 22:47:12 Philip Martin napisał(a):
>> Arfrever Frehtes Taifersar Arahesis <arfrever.fta_at_gmail.com> writes:
>>
>> > I would like to suggest that deprecated functions be additionally marked with
>> > __attribute__((deprecated)) [1]. I suggest to directly use SVN_DEPRECATED
>> > which can be defined in a header (e.g. svn_types.h) by:
>> > #define SVN_DEPRECATED __attribute__((deprecated))
>>
>> We are committed to supporting old interfaces for the lifetime of 1.x
>> and they should continue to work as well as they ever did.
>
> I agree that we should support old interfaces for the lifetime of 1.x, but
> IMO it doesn't disallow us to print warnings during compilation.
> The run-time behavior (which is more important) of these interfaces would
> still remain unchanged.
>
> --
> Arfrever Frehtes Taifersar Arahesis
>
Received on 2008-08-18 23:25:49 CEST