| [cdt-dev] FW: Proposal for Release Schedules |
|
Yes closing off mid-April is what I had in
mind. I think with our current numbers, we should have an easier time being
more disciplined at meeting that goal. In the past we’ve always over
committed and we didn’t have a project lead that made sure we had plans
and stuck with them (sorry Sebastien J). Having been a development manager in a recent past life, I
promise I’ll bring those skills back and make sure we deliver on our
promises. I’m not stuck with the version name
and I don’t think any other projects are lining up. Calling the June
release 3.1 works for me. My biggest concern is that if we let 3.1
drift past the end of June, then vacation season kicks in and I didn’t
like how that went last year and it actually delayed us a month. And from what
Erich Gamma says, this is also the biggest reason the platform releases then. Thanks, Leo, great feedback, From:
That does make the
discussion more interesting… What I think you are suggesting is
that our release plan be:
> but it would give us two and a half months for our release
candidate cycle Are you suggesting that we have a feature
complete – development freeze milestone in mid-April? I would agree
to that, but it might take a little more “discipline”
;-) than we have displayed in the past. Regarding the version name, I’m not
sure that it is worth trying to line up release numbers. For example, in
the future we may decide to have a “major change” release that
needs to be called 4.0 before the Platform does. Regards, Leo From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer 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 · · 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 >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 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 ------ Attachments are virus free! This message has been scanned for viruses at the originating end by Nemx Anti-Virus for MS Exchange Server/IMC http://www.nemx.com/products/antivirus
------ Attachments are virus free! This message has been scanned for viruses at the originating end by Nemx Anti-Virus for MS Exchange Server/IMC http://www.nemx.com/products/antivirus
|
Friday Feb. 17, 2006 - Milestone 5 (3.2 M5) - stable build
- API complete - API freeze