> >> 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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ parted-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/parted-devel
