Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] RE: CDT 1.0 release plan

Hi all,

just want to post an update on where we are with the CDT release. 
As folks have noticed, we've posted the freeze builds over the last
couple of weeks, but there's still been quite a lot of
bugfixing and features going in since then, for a couple of reasons:

- the amount of formal testing on platforms other than QNX has been
somewhat limited, so the list of bugs to fix has been relatively low.
I don't know if this is because the bugs are simply not there, or have
not been uncovered yet. As an FYI, John Healy's team at 
RH has done some testing on Linux, and will report back 
here on this.

- Judging from the feedback in the newsgroup, it seems there's been
some uptake of the CDT builds over the last month. This is 
encouraging, but has resulted in additional issues to tackle 
(and feature requests).

- Because of this, the CDT developers have not been fully occupied
doing pure bug fixing. It seemed reasonable to push through the 
assembly and memory view to get to a CDT 1.0 that would be satisfactory
for users.

- As we reach the end of October, I think we need to close out the
1.0 release. I've listed below a bug list from bugzilla, with those 
that need to be tackled (stoppers) at the top. Unless there are
significant issues that are lurking and have not been filed yet,
the CDT seems in quite good shape from a user perspective.

- There has been much discussion on whether this should be a 1.0,
or 0.x release, because of the roughness of the API's. I believe this
should be a 1.0 release. The original plan for the CDT (from July)
had all API's for the 1.0 release as "preliminary", which definitely
means subject to change, so we should not be too 
concerned about API backwards compatibility, provided 
that is made clear to companies that are downloading and 
working with the CDT.
I also strongly believe that in order to gain users for the CDT, 
a "blessed" version has to be available (1.0 as opposed to
nightly/freeze builds). My recommendation is to go for a 1.0
release (a "users" release), with the caveat about backwards-
compatibility of APIs. We also have the option of putting out
a 1.1 release shortly thereafter.

Any thoughts/comments?


____Pared down list of current bugs from bugzilla on CDT ____



UI/SWT bugs -- should be re-assigned
24785 (Linux GTK port)
23049 (Most likely core SWT issue)


I've excluded the feature requests that are targetted to future
releases of the CDT.

-----Original Message-----
From: Judy Green [mailto:jgreen@xxxxxxx]
Sent: Wednesday, October 23, 2002 11:11 AM
To: 'cdt-dev@xxxxxxxxxxx'; cdt-core-dev@xxxxxxxxxxx;
Subject: RE: [cdt-dev] Re: [cdt-core-dev] CDT 1.0 release plan

I also agree that we must be very careful about freezing the APIs.
I am also a lot uncomfortable with marking builds as freezes when we do not
have a full test plan (on all supported platforms) in place that would give
us a basic level of confidence in what we are putting out there.
I'd feel a lot better if we had a build-release process in place, with
enough resources allocated to do the job correctly.
-----Original Message-----
From: Schaefer, Doug [mailto:dschaefer@xxxxxxxxxxxx]
Sent: Wednesday, October 23, 2002 10:33 AM
To: 'cdt-dev@xxxxxxxxxxx'; cdt-core-dev@xxxxxxxxxxx;
Subject: RE: [cdt-dev] Re: [cdt-core-dev] CDT 1.0 release plan

I'd have to agree with the backward compatibility rule.  I think there has
to be a lot more evaluation on how the APIs will be used before we can
freeze them or else we won't be very happy in the long run.
I don't mind releasing more often in the early stages especially if there is
unfinished work that we were planning on delivering at the end of October
that needs finishing.  There are some things we are Rational would like to
work on over the next few months (and I'll put out a mail shortly explaining
that) that certainly wouldn't be ready before 2003.  So we'll have to get an
understanding of when the appropriate time for doing this is so that we
don't mess up any of these releases.
Whatever we decide, we need to be clear about what is delivering when.
There are companies that are making business plans with the CDT who need a
certain level of predictability.  As plans change, we need to make sure we
look down the pipe to understand the affects of these changes.
Doug Schaefer 
Senior Staff Software Engineer 
Rational - the software development company 
Ottawa (Kanata), Ontario, Canada 
-----Original Message----- 
From: Alain Magloire [mailto:alain@xxxxxxx] 
Sent: Wednesday, October 23, 2002 9:31 AM 
To: cdt-core-dev@xxxxxxxxxxx 
Cc: cdt-dev@xxxxxxxxxxx; cdt-debug-dev@xxxxxxxxxxx 
Subject: [cdt-dev] Re: [cdt-core-dev] CDT 1.0 release plan 
> As a final note, people have suggested that we do another interim release 
> in a couple of months to address bugs that will be reported, as well as 
> add in the missing features to the debugger (memory browsing and
> I like the idea, and suggest we discuss the schedule after the 1.0 release

> is out. 
> Any comments? If everyone is in agreement, we will post this release plan
> the web site and newsgroup. 
A couple: 
- I would not call it 1.0, but rather 0.8 or 0.9, 0.xx.  Using a major
  implies we have to follow some backward compatibility etc .. And for 
  such a young project with so little exposure ... an impossible task. 
- Certainly would like to make release as often(or more often) say 
  2 other releases before 2003. 

cdt-dev mailing list 

Back to the top