[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] CDT Release Schedule Proposal
|
>If we want to stick to bug fixes at Development Freeze, then we need to
>plan out APIs very thoroughly, and will need interested consumers to
>adopt early.
I think we should plan APIs thoroughly, but if it is discovered during
our test cycle that an API has a problem, I consider that a bug fix.
>but with
>no milestones planned, I'm not sure how people could hope to try
>adopting early because it will be somewhat nebulous as to when a given
>feature is going to be delivered in the development cycle.
I think a lot of people want to wait until the project is considered
"done" before investing a lot of time in testing it. If we are serious
about feature freeze, then I hope that people who integrate into CDT
realize it is in their own best interest to ensure that we haven't
"broken" them. If someone is interested in using a new feature, they
can coordinate with the developer (through status meetings, or more
frequently if necessary) to find out when it is going to be done.
Leo
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Recoskie, Chris
Sent: Wednesday, December 07, 2005 10:20 AM
To: CDT General developers list.
Subject: RE: [cdt-dev] CDT Release Schedule Proposal
Some comments:
If we want to stick to bug fixes at Development Freeze, then we need to
plan out APIs very thoroughly, and will need interested consumers to
adopt early.
We had a bit of a problem on 3.0 of people not having the time to truly
try out CDT until it was supposed to be in the can (and I'm just as
guilty of that as anyone because I was too busy implementing features).
With a long run at 3.1 hopefully this will be less of an issue, but with
no milestones planned, I'm not sure how people could hope to try
adopting early because it will be somewhat nebulous as to when a given
feature is going to be delivered in the development cycle.
But I agree, our previous milestone plans haven't been great.
Not casting my vote yet... looking to see a bit more discussion first.
___________________________________________
Chris Recoskie
Software Designer
Texas Instruments, Toronto
http://eclipse.org/cdt
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On
> Behalf Of Doug Schaefer
> Sent: Tuesday, December 06, 2005 11:49 AM
> To: CDT General developers list.
> Subject: [cdt-dev] CDT Release Schedule Proposal
>
> Hey gang,
>
> I'd like to propose the following release schedule plan. Please let me
> know
> if this works/doesn't work for you. I'm pretty open to changing the
dates
> give or take a couple of weeks.
>
> CDT 3.0.2 - Running on Eclipse 3.1.2 (Scheduled for Jan sometime)
> - RC0 build - Jan 28, 2006
> - GA build - Feb 11, 2006
> - GA release - Feb 16, 2006
>
> CDT 3.1 - Running on Eclipse 3.2 (Scheduled for June)
> - Integration builds for every Eclipse milestone
> - No milestone builds for CDT
> - RC0 build - April 14, 2006 - development freeze
> - GA build - day of Eclipse 3.2 release
> - GA release - Friday of week after
>
> Having no milestones is pretty controversial. But we've never been
good at
> putting together milestone plans which made milestone builds pretty
> meaningless. We will do integration builds that are blessed to work
with
> Eclipse milestones as they come out.
>
> Development freeze means bug fixes only going forward. As Leo
mentioned,
> we
> really need to be more disciplined with that going forward.
>
> Also note these are planned dates. We will not deliver a release if
there
> are bugs open against it.
>
> Please comment,
> Doug
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
