Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] CDT Roadmap Proposal

Hey gang,

There is a lot of planning work going on which is great to see! As well, 
we have more companies than ever interested in including the CDT in their 
product plans. It is critical for all these activities that we understand 
when we are going to put out CDT releases and what is going to be in each 
of these releases.

To help this along, I would like to propose a roadmap so that we can all 
be on the same page. Please feel free to provide your feedback and propose 
changes that would better meet your needs. Here we go:

Currently, on the table we have our (IBM's) proposal to release the 2.0.1 
snapshot of the 2.0 maintenance stream by the end of August. We would like 
to propose that the final build for this snapshot be on Thurs morning Aug 
26. We have committed resources to do regression testing on this release 
and will ask for a respin as necessary. This release, as is true for all 
maintenance releases, is only for bug fixing. The biggest change we have 
made is to bring in some major improvements to parser performance.

Also on the table is QNX's proposal to release 2.1 off of the main branch 
by the end of October (the illustrious Halloween release!). You guys can 
correct me if I miss anything but I believe this release will contain 
improvements and completion of the type hierarchy and class browser 
features introduced in 2.0 and some major debugger enhancements. As well 
we may try to squeeze even more performance enhancements to the parser if 
we have time after taking a breath from 2.0.1. There is also expressed 
desire to bring some of the managed build enhancements to this release if 
possible.

With those out of the way, I'd like to propose a somewhat regular schedule 
that we can count on for our collective future product planning. Despite 
objections, the feedback I've received from various sources is that it is 
critical that we line up with major Eclipse platform releases. These 
appear to be happening yearly. Eclipse 3.1 is scheduled for 2Q05 so I'd 
like to propose that CDT 3.0 be scheduled to release on the same day as 
Eclipse 3.1. This will require a good understanding of the changes Eclipse 
is planning and a good working relationship with them to ensure we don't 
repeat the Eclipse 3.0/CDT 2.0 experience. This release would have the 
work by Intel and others on managed build as well as our planned scalable 
AST (DOM) work. I'm sure we'll see other goodies like the remote systems 
model.

Beyond that if Eclipse stays on a yearly schedule, I can see where we 
still need to be more often than that. As such, I'd like to propose that 
we keep on a 6 month release cycle. As the CDT matures, we should be able 
to move to yearly releases as well.

As for maintenance releases. I propose creating branches at RC0 time for 
each release. From that point on only bug fixing should go into the branch 
and committers should make every effort to ensure that people can take a 
snapshot at any time after the release and use it for commercial purposes. 
We would release official CDT maintenance releases only if someone steps 
up to do regression testing on the release (as happened with 1.2.1 and 
will happen with 2.0.1).

Thoughts?

Doug Schaefer, IBM's Eclipse CDT Architect
Ottawa (Palladium), Ontario, Canada


Back to the top