Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] Initial CDT 3.0 plans


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

Some note on the content:  
- I've not committed anyone to anything at this stage, it is up to you to
that you want to take an item from proposed to committed.  
- I've taken the liberty of seeding certain activities in the proposal area.
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
execution) as a community and as the first paragraphs indicate "plans are
entirely static".  

So with that said ... Here is the first cut.

CDT 3.0: Let the Good Times Roll!

Title: CDT DRAFT 3.0 Plan

CDT Project
3.0 Plan (Draft template)

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:

  • Committed plan item - A committed plan item is one that we have decided to address for the release.
  • Proposed plan item - A proposed plan item is one that we are considering addressing for the release. Although we are actively investigating it, we are not yet in a position to commit to it, or to say that we won't be able to address it. After due consideration, a proposal will either be committed, deferred, or rejected.
  • Deferred plan item - A reasonable proposal that will not make it in to this release for some reason is marked as deferred with a brief note as to why it was deferred. Deferred plan items may resurface as committed plan items at a later point.
  • Rejected plan item - Plan items that were proposed but judged unworkable are marked as rejected plan items, with an accompanying summary of why they were dismissed. Keeping track of rejected items avoids repeating the discussion.

Release deliverables

The release deliverables:

  • Source code release for CDT Project, available as versions tagged "CDT_30" in the CDT Project CVS repository.
  • CDT Project (downloadable).
  • CDT runtime binary distribution (downloadable).

Release milestones

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:

    Eclipse 3.1 M4 based builds
  • Friday Jan. 7,2005 - Milestone 1 (3.0 M1) - initial tool and process spin up
  • Friday Feb. 4,2005 - Milestone 2 (3.0 M2) - stable build reflecting progress
    Eclipse 3.1 M5 Feb 18,2005
  • Friday Mar. 4,2005 - Milestone 3 (3.0 M3) - stable build reflecting progress
  • Friday Apr. 1,2005 - Milestone 4 (3.0 M4) - initial API freeze for breaking changes
    Eclipse 3.1 M6 Apr 1, 2005
  • Friday May 6,2005 - Milestone 5 (3.0 M5) - API freeze, stable build focus on clearing bug backlog
  • Friday Jun. 3,2005 - Milestone 6 (3.0 M6) - stable build, feature complete, RC0

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)

    Note these dates are conditional on Eclipse 3.1 schedule
  • Wednesday Jun. 15,2005 - Release Candidate 1 (3.0 RC1)
  • Friday Jun. 24, 2005 - Release Candidate 2 (3.0 RC2)
  • Friday Jul. 1, 2005 - Release Candidate 3 (3.0 RC3)
    Eclipse 3.1 GA expected ~July 1
  • Wednesday Jul. 13, 2005 - Release Candate 4 (3.0 RC4)

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.

Compatibility of Release 3.0 with 2.1

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.

CDT Project Themes & Priorities

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.

Theme 1: Performance and Scalability

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

Committed Items


Proposed Items (Eclipse Platform subproject, Performance theme)

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

Theme 2: User Experience

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.

Committed Items


Proposed Items (Eclipse Platform subproject, User Experience theme)

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

Other CDT Items

Committed Items (no theme)

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

Back to the top