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.