To add a little fuel to the fire, Eclipse
has released their full milestone schedule for 3.2.
· Friday Aug.
12, 2005 - Milestone 1 (3.2 M1) - stable build
· Friday Sep.
23, 2005 - Milestone 2 (3.2 M2) - stable build
· Friday Nov.
4, 2005 - Milestone 3 (3.2 M3) - stable build
· Friday Dec.
16, 2005 - Milestone 4 (3.2 M4) - stable build
· Friday Feb. 17, 2006 - Milestone 5 (3.2 M5) - stable build
- API complete - API freeze
· Friday Mar. 31, 2006 - Milestone 6 (3.2 M6) - stable build
- feature complete - development freeze - lock down and testing begins
Now if I read that correctly, that gives
them a three month release candidate cycle. That should actually give us enough
time to release the CDT at the end of June on the same day as the platform. I
think we still need two weeks after every milestone to adopt any changes, but
it would give us two and a half months for our release candidate cycle.
How does that sit with everyone,
especially those with product plans for the CDT next year? That would really
mean that we couldn’t do anything significant for a Feb CDT release
making it a 3.0.2.
But then what do we call the CDT release.
I liked lining up the version numbers.
Doug
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Treggiari, Leo
Sent: Thursday, November 10, 2005
9:49 AM
To: CDT
General developers list.
Subject: RE: [cdt-dev] Proposal
for Release Schedules
>So my proposal is this: move HEAD to Eclipse 3.2, which
requires some code changes due to API changes in the abstract editor and allows
us to start working towards any new APIs that are coming (e.g. debug). Use the
cdt_3_0 stream for the next release towards the end of Feb.
I agree.
+1
Regards,
Leo
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent: Thursday, November 10, 2005
9:41 AM
To: CDT
General developers list.
Subject: [cdt-dev] Proposal for
Release Schedules
Hey gang,
We talked about this at this month’s conference call
and I’d like to get the community’s input and call for a vote on
this.
Essentially, we want to avoid triple streaming. We have a
need to move to Eclipse 3.2 before API freeze happens next month to validate
that we are happy with any API changes (which we aren’t but kind of lost
that first battle). We are also considering maintenance work on the CDT 3.0.x
stream for the Jan timeframe. And finally, we have some sizable changes that we
had considered for a CDT 3.1 for Feb/Mar.
I think this is a little too much release activity for the
number of committers we have working on the CDT today, and the consensus on
call was that this was that we should probably only have one release in the
Feb-ish timeframe. What we haven’t figured out if there will be enough
content to call it a 3.1 or if it could be a 3.0.2. But we can work that out as
we go.
So my proposal is this: move HEAD to Eclipse 3.2, which
requires some code changes due to API changes in the abstract editor and allows
us to start working towards any new APIs that are coming (e.g. debug). Use the
cdt_3_0 stream for the next release towards the end of Feb.
Toughts?
Doug