Re: [cdt-dev] Scheduling update: CDT 2.1 and CDT 3.0

["Alain Magloire" <alain@xxxxxxx>]

> 
> Hey gang, to make sure everyone is kept up to date,
> 

Thanks, not all committers can make it to the meetings. 
And we want things to be transparent to encourage participants.

> At yesterday's conference call we discussed the delivery schedule for 2.1 
> and 3.0. I think it will be easier to schedule in the code freeze date, 
> i.e. the date when we can make our first release candidate. Here are the 
> proposed code freeze (RC0) dates for the next two releases.
> 
>         2.1 - Tuesday, Nov 2, 2004
>         3.0 - Tuesday, Apr 12, 2004 (Note this is over a week after 
> Eclipse 3.1 has scheduled their code freeze)
> 
> After these dates, we'll go into a release candidate cycle until we have a 
> build that has satisfactory quality. This usually takes around 4 weeks but 
> that depends on how much test pressure we can get from the community 
> during this time. If we don't get testing done and bugs found we'll have 
> to assume the quality is good enough. (So please help! :-)
> 

We were not to keen about 2.1 so shortly after the 2.0.x series but
I think we have enough good material in the head to make the 2.1 release
stand on its own.

> As for milestone builds, we should target building CDT 3.0 against the 
> milestone releases of Eclipse 3.1 (i.e. not integration builds). We'll aim 
> for building on the Tuesday after the Friday milestone releases starting 
> with M3 on Nov 9. If we find these CDT milestone builds too unstable, we 
> can delay as necessary.
> 

To not have a repeat of the greek tragedy of last year, let's be clear
on the rules of engagement for CDT-3.0.  The problem last year was
CDT head was tracking the Eclipse nightly builds, I would propose, this time around,
that we track the latest Eclipse milestone.  It should give the committers
some breathing room.  Of course this is not set in stone, if we look at last year some Eclipse
milestones were so bad quality we had to regress to a previous build.


> After these releases, we have usually found the need to do a maintenance 
> release within a couple of months of the main release and will then 
> continue to do maintenance releases as we find major bugs.
> 

+1

> Thoughts?
>