| [cdt-dev] Initial CDT 3.0 plans |
Folks, Derrick Keefe and I have been working out some of the rough details for the CDT 3.0 release. We meant to have a CDT 3.0 planning session last week but it seems that the Christmas release schedule has caught up with us here at QNX. So rather than an initial conference call, I'm going to throw a draft plan out there for general comment and we will be able to comment on it formally in the January conference call (which with Christmas is not all that far away). Some note on the content: - I've not committed anyone to anything at this stage, it is up to you to indicate that you want to take an item from proposed to committed. - I've taken the liberty of seeding certain activities in the proposal area. These are all items that have been culled from Bugzilla or from previous discussions on the mailing list or from direct CDT user experience feedback. - Nothing is written in stone. We decide on this plan (and more importantly its execution) as a community and as the first paragraphs indicate "plans are not entirely static". So with that said ... Here is the first cut. CDT 3.0: Let the Good Times Roll! ThomasTitle: CDT DRAFT 3.0 Plan
Initial Document December 20, 2004
Please send comments about this draft plan to the cdt-dev@xxxxxxxxxxx
developer mailing list.
This document lays out the feature and API set for the next feature release of CDT after 2.1, designated release 3.0
Plans do not materialize out of nowhere, nor are they entirely static. To ensure the planning process is transparent and open to the entire Eclipse community, we (the CDT Project) post plans in an embryonic form and revise them throughout the release cycle.
The first part of the plan deals with the important matters of release deliverables, release milestones, target operating environments, and release-to-release compatibility. These are all things that need to be clear for any release, even if no features were to change.
The remainder of the plan consists of plan items for the CDT Project. Each plan item covers a feature or API that is to be added to CDT. Each plan item has its own entry in the Eclipse bugzilla database, with a title and a concise summary (usually a single paragraph) that explains the work item at a suitably high enough level so that everyone can readily understand what the work item is without having to understand the nitty-gritty detail.
Not all plan items represent the same amount of work; some may be quite large, others, quite small. Some plan items may involve work that is localized to a single component; others may involve coordinated changes to several components; other may pervade the entire CDT Project. Although some plan items are for work that is more pressing than others, the plan items appear in no particular order.
With the previous release as the starting point, this is the plan for how we will enhance and improve it. Fixing bugs, improving test coverage, documentation, examples, performance, usability, etc. are considered routine ongoing maintenance activities and are not included in this plan unless they would also involve a significant change to the API or feature set, or involve a significant amount of work. All interesting feature work is accounted for in this plan.
The current status of each plan item is noted:
The release deliverables:
Release milestone occurring at regular intervals (~4 weeks) exist to facilitate
coarse-grained planning and staging.
Synchronization Expectations
Once an Eclipse platform 3.1 milestone build is released, it will be vetted for
use by a subset of the CDT development team. Once approved as stable, all CDT
3.0 development must move to that release of the Eclipse platform.
Once a CDT milestone build is complete, developers performing large scale
CDT integration will be expected to move forward to using that build for
development. Every effort will be made to ensure that the CDT milestone
builds are stable platforms for performing CDT integration, though perhaps
not suitable for large scale C/C++ development.
The milestones are:
Lock down and external testing begins with M6 and progresses through a series of test-fix phases against candidate releases. Release candidate builds are planned as follows (M6 is RC0)
Depending on the circumstances, and on the stability of Eclipse 3.1, we may add additional release candidate builds or fine-tune the schedule. The 3.0 release is targeted for the week of July 13, 2005. All release deliverables will be available for download as soon as the release has been tested and validated in the target operating configurations listed below.
CDT will be forward compatible with CDT 2.1. The nature and scope of some of the key plan items are such that the only feasible solutions would break compatibility. Since breaking changes are a disruption to the CDT community they cannot be taken lightly. We will have an open discussion with the community before approving a proposed breaking change for inclusion in 3.0. We aim to minimize the effort required to port an existing product to the 3.0 APIs. We will provide a comprehensive CDT 3.0 Porting Guide that covers the areas of breaking API changes, and describes how to port existing 2.1 extensions to 3.0. Up-to-date drafts of the CDT 3.0 Porting Guide will be included with milestone builds so that it's possible to climb aboard the 3.0 release wagon at the early stages, or to estimate the amount of effort that will be involved in eventually porting existing extensions to 3.0.
API Contract Compatibility: CDT 3.0 will be upwards contract-compatible with CDT 2.1 except in those areas noted in the CDT 3.0 Porting Guide. Programs that use affected APIs and extension points will need to be ported to CDT 3.0 APIs. Downward contract compatibility is not supported. There is no guarantee that compliance with CDT 3.0 APIs would ensure compliance with CDT 2.1 APIs. Refer to general Eclipse document on Evolving APIs for a discussion of the kinds of API changes that maintain contract compatibility.
Binary (plug-in) Compatibility: CDT 3.0 will be upwards binary-compatible with CDT 2.1 except in those areas noted in the CDT 3.0 Porting Guide. CDT 3.0 will include additional runtime compatibility mechanisms to provide effective binary API compatibility. Downward plug-in compatibility is not supported. Plug-ins/Extensions for CDT 3.0 will not be usable in CDT 2.1. Refer to Evolving CDT APIs for a discussion of the kinds of API changes that maintain binary compatibility.
Source Compatibility: CDT 3.0 will be upwards source-compatible with Eclipse SDK 3.1 except in the areas noted in the CDT 3.0 Porting Guide.
Workspace Compatibility: Workspaces containing CDT 2.0 and CDT 2.1 projects will be forward migrated.
Non-compliant usage of API's: All non-API methods and classes, and certainly everything in a package with "internal" in its name, are considered implementation details which may vary between operating environment and are subject to change without notice. Client plug-ins that directly depend on anything other than what is specified in the CDT API are inherently unsupportable and receive no guarantees about compatibility within a single release much less with an earlier releases.
Plan items reflect new features of CDT, or areas where existing features will be significantly reworked. Many of the changes under consideration for the next release of the CDT address two (2) major themes. Since each theme has a number of items, the committed, proposed, and deferred plan items are grouped in sections by theme:
In addition, there are important CDT improvements that do not naturally fit into any of the above themes.
Working with C/C++ source offers a number of unique challenges. Work is underway to improve the scalability of the underlying source code model to provide more rapid responses (for searching and cross referencing) and more accurate results (for refactoring and outlining).
Reduce indexing time and cost. bugzilla ref. (####)
in progress
Parser/Scanner language extensions. bugzilla ref. (####)
in progress
CDT AST/DOM creation. bugzilla ref. (####)
in progress
C/C++ Language Variants. This work would add the possibility to add new compiler/language specific capabilities into the parser (ie GNU extensions) bugzilla ref. (####)
in progress
Error parser re-design. Work to specifically improve the performance of the error parsers and to improve their programatic interface. bugzilla ref. (####)
in progress
A continued goal for the CDT development team is enabling C/C++ developers to simply start developing without requiring an enormous amount of set-up and configuration where avoidable. There is much work in this area, specifically around the Managed Build System.
Remote system (was target) model definition. The CDT is heavily used by embedded developers and various OEM/VARs. One common theme that each group must re-invent is the concept of their remote system. This activity proposes to unify that interface. bugzilla ref. (####)
in progress
Managed build system. bugzilla ref. (81450)
in progress
Debugger specialization for gdb embedded. Further GDB specific enhancements to facilitate working with embedded targets. bugzilla ref. (####)
in progress
Debugger memory view. Synchronization of the debugger's memory view with the platform generic memory view. bugzilla ref. (####)
in progress
Launch configuration UI adjustment. A simplification of the CDT launch configuration panels to simplify and speed-up the time from code to debug. bugzilla ref. (####)
in progress
Template extension point for new projects . Initial extension point used to create code template stubs for new projects (ie KDE/GNOME/Win32 application, command line application, shared library etc) bugzilla ref. (####)
in progress
Better support for nested projects and linked resources . bugzilla ref. (####)
in progress
Proposed Items ( no theme)
Pervasive use of workspace variables . This helps developers create location independant projects and all paths/symbols created in the CDT should be "variable" aware. bugzilla ref. (####)
in progress
Enhanced refactoring . bugzilla ref. (####)
in progress
Source based hover help . Using the comments within the source and headers to provide content dynamic hover help and content assist help. bugzilla ref. (####)
in progress
Java based C/C++ code formatter . A java native (ie portable) based code formatter. bugzilla ref. (####)
in progress
Improved ISV documentation . bugzilla ref. (####)
in progress
- Follow-Ups:
- [cdt-dev] Re: [cdt-core-dev] Initial CDT 3.0 plans
- From: David Daoust
- Prev by Date: Re: [cdt-dev] GUI development w/Eclipse & CDT
- Next by Date: Re: [cdt-dev] Parallel Tools
- Previous by thread: [cdt-dev] Time to move to Eclipse 3.1?
- Next by thread: [cdt-dev] Re: [cdt-core-dev] Initial CDT 3.0 plans
- Index(es):