CDT 7.0 for Helios

View: New views
7 Messages — Rating Filter:   Alert me  

CDT 7.0 for Helios

by ken.ryall :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

CDT 7.0 for Helios 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

Re: CDT 7.0 for Helios

by subs-6 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On 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 Helios

by Doug Schaefer-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Thanks, 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:
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



_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

Parent Message unknown Re: CDT 7.0 for Helios

by John Cortell-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Freescale also takes, develops against, and deploys the stack in its entirety. Thus, API breakage is not a big concern for us...as long as they're not behavioral breaks, as those go undetected at build time and ultimately are discovered through a runtime bug (not good).

John

At 02:18 PM 11/4/2009, Doug Schaefer wrote:
Thanks, 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:
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


_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

Re: CDT 7.0 for Helios

by Christian W. Damus-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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<--------



Christian W. Damus
Software Developer, IDE Team
QNX Software Systems

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

RE: CDT 7.0 for Helios

by Schorn, Markus :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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.


From: cdt-dev-bounces@... [mailto:cdt-dev-bounces@...] On Behalf Of ken.ryall@...
Sent: Wednesday, November 04, 2009 9:05 PM
To: cdt-dev@...
Subject: [cdt-dev] CDT 7.0 for Helios
Importance: Low

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

Re: CDT 7.0 for Helios

by Pawel Piech :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Schorn, Markus wrote:
CDT 7.0 for Helios
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.
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