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.