[
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?
Sebastien
____Pared down list of current bugs from bugzilla on CDT ____
High-priority
25112
25283
24030
24648
23002
UI/SWT bugs -- should be re-assigned
24785 (Linux GTK port)
23049 (Most likely core SWT issue)
Low-priority
24229
23601
23478
25176
24574
24409
24023
23879
23603
23602
23258
24652
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;
cdt-debug-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.
-Judy
-----Original Message-----
From: Schaefer, Doug [mailto:dschaefer@xxxxxxxxxxxx]
Sent: Wednesday, October 23, 2002 10:33 AM
To: 'cdt-dev@xxxxxxxxxxx'; cdt-core-dev@xxxxxxxxxxx;
cdt-debug-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.
Cheers,
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
assembly).
> 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
on
> 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
version
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
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev
