Hi Markus,
On the debugger side we have been following these
rules since the beginning. And I have always opposed to what Doug
calls "a cowboy approach".
But since I have started to look at the other parts
of CDT (core and build) I have had problems to understand what
is meant to be API there and what is not. Some developments
seem to be started but then abandoned. Some old interfaces are marked as
deprecated without mentioning the replacements for it, others are left
without deprecation. In some cases I couldn't understand why a
class or an interface was implemented as public or internal. It
seems that people who work closely with core (and possibly build) have
an understanding of what is public but it is not obvious for
outsiders like myself.
My opinion is: a serious cleanup is required
which may cause an API breakage. Not sure if we have resources for it
though :(
Regards,
Mikhail
Hi
committers,
For two
reasons, I am missing a discussion about the planned changes to the API.
* Even if we
deliver CDT 6.0 and thus do break API, we should be nice to our clients
and keep
the
changes to the API minimal. Therefore an API change needs
some justification. In many cases
it is possible to provide a fix that only
extends, but does not break API.
* A single
committer is usually not aware of all the use-cases for an API and
therefore an API change
should be discussed before it is carried
out.
Basically
I
would like to know about the planned API changes, but I also think that
we should take this
further by
making it mandatory to discuss a breaking change to AP on bugzilla,
first. It is also a good
habit to
inform committers about non-breaking extensions to
API.
Please share
your opinion,
Markus.
--
IMPORTANT NOTICE: The contents of
this email and any attachments are confidential and may also be
privileged. If you are not the intended recipient, please notify the
sender immediately and do not disclose the contents to any other person,
use it for any purpose, or store or copy the information in any
medium. Thank
you.