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
