[parted-devel] Deprecation method

[Jason Irvan]

> >> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/parted-devel/attachments/20061217/7fe7156c/attachment.pgp