[cdt-dev] CDT 1.2 Proposal (Content & Timeframe) in Text Format

[Kleanthis Hapitas <khapitas@xxxxxxxxxx>]

As requested, I am re-posting the CDT
1.2 content and timeframe proposal in text form rather than as a Doc attachment.

Kleo
__________________


Hello all,

As discussed on the last CDT conference
call in mid-May, we need to start getting our heads around what we want
to do for the next release (beyond 1.1) of the CDT. During the call I had
offered to capture IBM-Rational's thoughts on the next release and share
them with the larger community as a starting point for further discussion.


The attached file captures the capabilities
that we have talking about adding to the CDT, as well as a proposed timeframe.
My goal in putting it out here is to generate some feedback so that we
can drive it from a proposal to something that is more like a plan of record.
I welcome any and all feedback to the proposal. It currently captures the
capabilities that Rational is working towards, so if there are areas where
others are planning or would like to contribute, feel free to provide some
input. For example, one of the areas that I have left essentially blank
is Debug. If any work is being planned in that area, it would be great
to capture that information as well. In addition to contributing code (features
and fixes), we should not forget testing. Any thoughts or comments on how
we can achieve greater test coverage (both functionality and scalability)
for the CDT is especially welcome.

Have a look and let's hear what you
think. I will summarize any feedback I get on upcoming conference calls,
and hopefully within the next couple of weeks we can add to and refine
what I have started to capture and share our plans for next release content
and timeframe on the CDT web site.

---------------------------------------------------------------------------------------------------------------------------------

CDT 1.2 Proposal (Timeframe & Content)

Overview

The purpose of this document is to capture
the current proposal for release 1.2 of the CDT, both from a content and
a timeline perspective. The objective is to gather comments and feedback
to the proposal in order to establish a plan of record for the 1.2 release
that satisfies the needs of the general CDT community.
Release 1.2 Content

The following sections will describe
the capabilities (from a user’s perspective) that we would like to add
or improve in the CDT for release 1.2. Initially this section will capture
all of the capabilities that are currently on the table for possible inclusion
in the 1.2 release. The goal will be to review and refine the content,
turning it from a wish-list into an actual plan of record for the release.
The list is somewhat ambitious and we will need help to realize it, so
part of the feedback we are looking forward to seeing is where others CDT
contributors may be able to help. Depending on our resources and on the
level of assistance from others, we might take the approach of introducing
some level of these capabilities, such as code completion for some constructs
or search for some types of references and then build on that.
Editing Capabilities

> Content/Code assist & complete
o Completion (with & without user
invocation) of C++ language constructs (eg if statements, for loops, etc.)

> Search for references
o Allows the user to search for different
kinds of references to a specific variable/function/object/method. Types
of matches to look for could include (Declarations, Implementers, References,
All Occurrences, etc.)

> Text hover
o Present the declaration and documentation
(in bubble help format) for a given identifier (variables, functions, class
names) when the mouse hovers over it.

> New Class Creation Wizard
o A wizard to automate the creating
of a new class

> Navigation Assistance
o Outline view
* Filters to show/hide things like static
members, non-public members, fields, etc.
* Open symbol’s source (open the header/cpp
file where this source is “defined”)
* Open header file referenced by a #include
(may require build system support to determine inclusion paths)


> Code Formatting
o A C/C++ equivalent of the JDT code
formatting preferences page.

> User settable file name extensions
(via preferences)

Build Capabilities

> Build a project using automatically
generated makefile(s)

Debug Capabilities

> Need content from QNX…(like plans
for remote debug for example)
Documentation

> Create documentation for the CDT
as it stands today (release 1.1) and begin documenting the capabilities
being added in 1.2 as time permits.
Other Enhancements for Release 1.2

> Looking for input from other CDT
members

Quality Engineering

        The
IBM (Rational) team will be dedicating some resources to test all of their
contributions to version 1.2 of  the CDT. In addition to that, we
(the broader CDT community) need to figure out how we might be able to
divide and conquer testing of other areas of the CDT that have not yet
received any real test coverage. Also, if we hope to get wide spread adoption
of the CDT, we will have to be able to verify its scalability (i.e. ability
to efficiently handle large scale C++ projects in terms lines of code,
classes, files, etc.) Any thoughts/ideas on these topics would be most
welcome.

Planned enhancements that will be post-release
1.2:

> Refactoring
o The ability to make system-wide code
changes, optionally previewing the changes that will result from the refactoring
operation

> Writeable DOM
o A writable DOM will be required in
order to support user-level capabilities like refactoring.

> Build a project using a build system
internal to the CDT (emulating the behavior of make?)

---------------
Timeframe
---------------
As discussed on the CDT call on Wednesday
May 21, the current proposal on the table is to have an incremental release
of the CDT (version 1.2) available at the end of August 2003, followed
by a 2.0 release at the end of the year. After some further discussions
and planning, the IBM-Rational team feels that mid-to-end of September
is the timeframe that some of the improvements being proposed (later in
this document) should be ready.  The fall release should be an incremental
release rather than a major one for the following reasons:

- APIs still likely to be churning
- Sufficient level of end-user documentation
may not yet be in place
- Verification activities may not be
rigorous enough yet


I’ll propose the following milestones
and dates for the 1.2 release, with a brief explanation for each. All of
the milestones are derived by working backwards in time from a GA milestone
at the end of August 2003. I look forward to receiving feedback on this
proposed timeframe from other CDT participants.

- Plan of Record in place:    
    June 13, 2003

        The
date by which we should we have a firm plan for the schedule and content
of the 1.2 release
        **
The CDT website should be updated at this time to reflect this plan going
forward.

- Milestone 1 (M1) :      
         August 15, 2003

        This
is the date by which all of the features that are intended for the release
have been pushed to the main stream and are stable enough for people to
start experimenting with and for QE teams to start testing with. The main
objective of this milestone is to provide verification teams enough time
to properly test the new features that have been delivered and to help
prevent surprises and unpleasant interactions from creeping in right near
the end of the release. Stabilization of the features will continue to
happen past this date as the features get soaked/tested and defects are
raised.

- Freeze 1 (F1):      
               
 September 5, 2003

        This
is the date by which all feature development and testing has been completed,
and major problems (high priority bugs) have been resolved. Changes to
the stream beyond this date should be controlled  and limited to fixes
for critical problems that would gate the release of the software.

- Release Candidate 1 (RC1):  
      September 16, 2003

        All
critical fixes have been made and a release candidate build is declared.
The CDT team would sanity test this build for a couple of days before declaring
it to be generally available. If show stoppers are discovered in the release
candidates, another release candidate will by cycled and the sanity testing
repeated.

- General Availability (GA):  
     September 19, 2003

        The
sanity testing has not discovered any show stoppers and the release candidate
build is declared to be ready for general availability.


----------------------- END OF PROPOSAL
-----------------------------------------------------------------------------------------------------------------------------------------

Regards,

Kleo Hapitas
Program Manager
IBM Software Group - Rational
Tel: (613) 591 2913