Hi All, On Thu, 2010-06-17 at 20:26 -0600, Leif Hedstrom wrote:
> Anyone else have any thoughts / comments on this topic ? Unless it gets > "voted" down, I'll file a bug and list the APIs that we'd remove from > the 2.2 release. Yes, it's semi painful, but I think in the long term, > it helps developers not use APIs that we no longer support (and which > have better versions anyways). First, I'm sorry I am a week late to this discussion. I know that's annoying. I think the proposed change almost always has negative consequences. This is a new project and in just its second release this change breaks compatibility of existing plugins. Over a change in minor version numbers no less! TS will get, fairly, a reputation for not having any kind of stable API or ABI and being a platform with a high maintenance burden to operate. I know the intention is to be developer friendly, but it really is the opposite of that for both plugin developer and administrator (who will find they cannot update their TS because their plugins require "porting" to 2.2 with no notable improvement in plugin functionality.). The 2.0 examples directory contains multiple uses of functions marked deprecated in the documentation. INKMimeHdrFieldValueInsert() is one such example. If the illustration code in the 2.0 release cannot abide by the deprecated warning it makes sense that developers reading that code would feel free to ignore it as well. If this change is made, example plugin code that is shipped as part of 2.0 will not run or compile on 2.2. That breaks reasonable user expectations. If there were a solid technical reason for removing the functions (i.e. they cannot be fixed to implement what they are defined to do, or their presence prevents the implementation of some other function or improvement) I would feel differently. But I don't see one here. I certainly have plenty of interfaces of my own that I have designed and then later wished never saw the light of day. But if they are public interfaces, then my experience really says it is best to just suck it up and live with them in perpetuity even if deleting them would be more convenient for me. In my opinion, there are several other better ways of improving plugin design decisions. First, clean up the example code to remove deprecated code. Second, clean up the documentation so the deprecated functions are not mixed in with the stuff you want people to use - exile them to a deprecated appendix. Third, use compiler attributes to nag people who do use them anyhow.. Finally, in a major release (i.e. 3.0) perhaps remove the SDK prototypes for the deprecated functions but preserve the code in order to maintain a stable ABI for old plugins. -Patrick
