|
View:
New views
7 Messages
—
Rating Filter:
Alert me
|
|
|
CDT 7.0 for HeliosThis 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 _______________________________________________ cdt-dev mailing list cdt-dev@... https://dev.eclipse.org/mailman/listinfo/cdt-dev |
|
|
|
Re: CDT 7.0 for HeliosOn 04/11/2009 20:05, ken.ryall@... wrote: > 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 > > > > _______________________________________________ > cdt-dev mailing list > cdt-dev@... > https://dev.eclipse.org/mailman/listinfo/cdt-dev Perhaps you could give some pointer as to what is 'up for change'. I can list most parts of CDT as being used by my product... ManagedBuildSystem Template Engine Debug (pretty much all of it) Project Wizards ProjectDescriptions etc etc -- Subs _______________________________________________ cdt-dev mailing list cdt-dev@... https://dev.eclipse.org/mailman/listinfo/cdt-dev |
|
|
|
Re: CDT 7.0 for HeliosThanks, Ken, you don't have to wait for me :).
A lot of the reason behind sticking with 6.1 was to show that we are managing our APIs carefully and not changing them. We've been bad at that in the past and sooner or later we need to change that. And adopting the API tooling as we did last release to monitor this was a great first step. But we've heard from a number of committers now that we're still not done. While we are managing APIs better, we still have technical issues with the APIs themselves and we need to resolve that. So I'm open to making this CDT 7.0. At the least, we should upversion the plug-ins that need to API changes to 7.0. And I'd prefer that the CDT "marketing" number always equal the highest version of our plug-ins. But, we do need to hear from the ISV community on how this impacts them. Do any vendors want to use plug-ins built against CDT 6.0 and have them to work against the Helios release. At Wind River, we've never done that, we always take a whole new stack from Eclipse. Doug. On Wed, Nov 4, 2009 at 3:05 PM, <ken.ryall@...> wrote:
_______________________________________________ cdt-dev mailing list cdt-dev@... https://dev.eclipse.org/mailman/listinfo/cdt-dev |
|
|
|
|
|
|
|
Re: CDT 7.0 for Helios
Hi,
At QNX we follow much the same pattern in configuration of our product, except that we slice-and-dice the CDT to take a subset. So, from our perspective, changes in bundle dependencies may have a similar impact as API breakage, but that shouldn't be difficult for us to adapt to. At least, not as the intent is to provide ample notice :-D I guess the important point from our perspective is that API breakage really address critical problems: fixing API that really isn't viable in its current state. The scanner-discovery API is a good example, and I for one am excited about the plans that Andrew and the team have for this. Cheers, Christian On Wed, 2009-11-04 at 15:18 -0500, Doug Schaefer wrote: --------8<-------- On Wed, Nov 4, 2009 at 3:05 PM, <ken.ryall@...> wrote: --------8<--------
_______________________________________________ cdt-dev mailing list cdt-dev@... https://dev.eclipse.org/mailman/listinfo/cdt-dev |
|
|
|
RE: CDT 7.0 for HeliosHi,
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.
_______________________________________________ cdt-dev mailing list cdt-dev@... https://dev.eclipse.org/mailman/listinfo/cdt-dev |
|
|
|
Re: CDT 7.0 for Helios
Schorn, Markus wrote:
Adding the "api" keyword to the bug would be good too. Then we could compile a list of such changes with a bugzilla query. -pawel _______________________________________________ cdt-dev mailing list cdt-dev@... https://dev.eclipse.org/mailman/listinfo/cdt-dev |
| Free embeddable forum powered by Nabble | Forum Help |