[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] CDT 7.0 for Helios
|
Title: CDT 7.0 for Helios
Hi,
In case it is necessary to make breaking API changes we
should do that with some care.
I would like to establish a minimal process for introducing
breaking API changes. Here is what
I'd like to see.
Bugzilla report with a proposed API change + an
email to the dev-list
Before making a breaking
API-change there should be an opportunity to discuss the
change.
An API is always some sort of lock-in and it is good
to have API reviewed/discussed. Especially if
we
make a breaking change we should get it
right.
Documentation of the breaking API change on the
Wiki
That's just fair for the ones that extend
CDT.
Deadline for breaking API changes
For late changes you usually don't spend
enough thought to make a good API. In addition there is not
enough time to detect potential flaws in the
API.
Detect unintentional API
breakage
To detect unintentional API breakage we can use the
API tooling (there is an option to report breaking
changes although the major version was increased).
Intended and documented API breakage can be
added to the problem filter, such that we instantly
see unintended breakage.
Create API that can be evolved in future
releases
As a general guidline:
* Expose as little as possible.
* Don't allow clients to implement interfaces of the
API (Either mark interfaces as @noimplement or use
an abstract class
instead.)
* Make
classes final or mark them as @noextend, unless you expect clients to extend the
class.
Markus.
Doug may have been planning to start talking about
this but it was on my mind this morning so I wanted to follow up on the list
with something we discussed on the CDT call yesterday: making the next release
of CDT for Helios (due next summer) version 7.0 instead of version
6.1.
This means that there would be some API breakage in a few focused
areas but that we would take care to document the changes so people
integrating with CDT would know what to expect. Although it is impossible to
know if anyone if using a given API, it is likely that the APIs we discussed
aren’t currently used or are in very limited use. Of course the 6.0.x stream
would be unaffected.
It would be good to hear from people who integrate
with CDT to find out which APIs are in common use so we can limit the impact
of any proposed changes.
Thanks - Ken
