[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[cdt-debug-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!
Thomas
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.
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).
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
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
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