API breakages - file bugs / update HACKING.txt ?

[Martin Pool]

On Thu, May 22, 2008 at 1:14 AM, John Arbash Meinel
<john at arbash-meinel.com> wrote:

> You end up accumulating a lot of cruft. And the second form is the same as
> the first, except you only create the thunk function when you actually need it,
> rather than all the time. At the expense that now all callers actually need
> to change what function they are calling, and your namespace gets polluted with
> thunk functions.
>
> I mentioned doing this a long time ago, but I think the consensus was that
> while we would preserve compatibility for callers, we wouldn't go for the overhead
> of doing so for implementers.

I think doing this for new APIs might be worthwhile, especially if it
is a class you expect will be subclassed, or where you are subclassing
it yourself.  Aside from helping plugins it would give a bit of
clarity about which methods are to be called and which are to be
overridden.

> I would certainly like to know what is breaking. If we are actually breaking
> clients versus implementers, etc. And knowing what functions are broken
> should certainly be documented.

I'd second that.  Maybe if Jelmer has some examples of particular
changes or types of changes we've done that were problematic that
would help us make better decisions.  And you're always welcome to say
that a particular API change has caused trouble.

-- 
Martin <http://launchpad.net/~mbp/>