+1
Here is a first notice about an intended API addition:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=251406
Toni
------------------------------------------------------------------------
*From:* cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] *On Behalf Of *Schaefer, Doug
*Sent:* Monday, October 20, 2008 3:48 PM
*To:* CDT General developers list.
*Subject:* RE: [cdt-dev] CDT 6.0 and API
+1.
Time to put the cowboy hats away. :)
Doug.
------------------------------------------------------------------------
*From:* cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] *On Behalf Of *Schorn, Markus
*Sent:* Monday, October 20, 2008 8:33 AM
*To:* CDT General developers list.
*Subject:* RE: [cdt-dev] CDT 6.0 and API
Thanks. We have a history of not doing the obvious. So we need
this discussion and also a formal
decision on a minimal agreement on how to carry out breaking and
non-breaking API changes.
For breaking API changes I suggest to have a
* mandatory bugzilla discussion.
* short description with link to the bugzilla on a designated
Wiki-page, such that we have an overview
about the breaking changes.
For non-breaking API changes we could have a mandatory note on
the cdt-dev list with a link to the
bugzilla.
Markus.
------------------------------------------------------------------------
*From:* cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] *On Behalf Of *Mikhail
Khodjaiants
*Sent:* Monday, October 20, 2008 1:09 PM
*To:* CDT General developers list.
*Subject:* RE: [cdt-dev] CDT 6.0 and API
*Importance:* Low
Markus,
If your intention is to make bugzilla discussions on API
changes mandatory then I support it absolutely. In my
opinion the rules you are suggesting are so obvious that
no discussion is required.
Mikhail
------------------------------------------------------------------------
*From:* cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] *On Behalf Of *Schorn,
Markus
*Sent:* Monday, October 20, 2008 11:54 AM
*To:* CDT General developers list.
*Subject:* RE: [cdt-dev] CDT 6.0 and API
Mikhail,
the definition of API is easy, it's the content of all
packages that are exported as public package in
the manifest.mf file. The API tooling will use exactly this
information for performing checks on the API.
If packages are unintentionally exported as public, we need
to remove the public export, which is a
breaking API change.
I did not start and argument about whether API changes are
necessary or not. I want to discuss, how
we can carry out API changes in an organized manner. What's
your opinion on that?
Markus.
------------------------------------------------------------------------
*From:* cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] *On Behalf Of
*Mikhail Khodjaiants
*Sent:* Monday, October 20, 2008 12:12 PM
*To:* CDT General developers list.
*Subject:* RE: [cdt-dev] CDT 6.0 and API
*Importance:* Low
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
------------------------------------------------------------------------
*From:* cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] *On Behalf Of
*Schorn, Markus
*Sent:* Monday, October 20, 2008 10:17 AM
*To:* CDT General developers list.
*Subject:* [cdt-dev] CDT 6.0 and API
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.
------------------------------------------------------------------------
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev