[parted-devel] Deprecation method

[Otavio Salvador]

Jason Irvan <jirvan at mailshack.com> writes:

>> >> 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.
>> > Yeah, that sounds reasonable.  But how will you detect that the user
>> > hasn't adapted?
>> 
>> We can't detect. Basically, we need to write a very clear announce
>> with a good documentation that warns the user about those changes and
>> make the compilation break. _IF_ we don't add the deprecation warning
>> and just change the API we ensure that user will need to review the
>> code and also read the porting doc. That could be a way to get it.
>> 
>
> I would recommend against breaking compatibility in the span of one
> release. This is a huge point of frustration for developers using any
> library. Is using another naming scheme for the new function(s) out of
> the question? That would allow both versions to co-exist at least for
> several revisions to allow developers time to port.
>
> What ever you decide I would recommend standardizing the process. That
> way developers know what to expect moving forward.

2.0 is a major release. Usually, when we have a major release we
expect that kind of change.

It is completely different until 1.8 release where we always keept the
backward compatibility.

-- 
        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."