[parted-devel] Deprecation method

[Otavio Salvador]

leslie.polzer at gmx.net writes:

> Hello folks, and esp. Otavio,
>
>   the __deprecated method to mark deprecation is good, but I fear it
> won't suffice for the partition guessing stuff (and everywhere else
> where signatures or semantics of functions have changed without changing
> the name).

But then this isn't a deprecation but a semantic change and shouldn't
be tag as a deprecation.

>   For example, 1.8 will return a zero or a one in the file system probe
> function. 2.0 will presumably return an integer between 0 and 100. When
> using a macro, we can have flexible semantics for legacy apps and new
> semantics for upgraded apps.

Why do you wish to change that? But in that case, we could the use a
LIBPARTED_BACKWARD_COMPATIBILITY definition to check and then use the
previous code. I just don't know if will be good to keep this.

Maybe would be better just break the compilation compatibility and
write a documentation explaning what has been change and how to port
the old application to the new code.

That would make our life easier and to make it even easier to
developers we can release a 1.9.90 version when we think it's ready
for they start to port to it. More or less as GNOME does.

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio at debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."