| [jakarta.ee-spec.committee] Freeze Date (Re: Agenda for the April 20th Jakarta EE Specification Committee call) |
| Picking up on Scott's comments here and the brief discussion the call. We need to establish and evolve the concept of a freeze date. There needs to be a date by which, in spirit, all specification work is complete, considered frozen and implementations are the only remaining obstacle. In practice, there will still be the need to address TCK challenges. The release date would be planned to be some number of weeks after the freeze date. If the freeze date moves, the release date moves by the same amount. In practice, things will still be messy by the time the freeze date comes. As the messes begin to show, we can evaluate each one and ask ourselves "do we think where this thing is at is is in spirit of where we should be by a freeze date?" If the answer is no, then we have to either push the freeze date (and therefore the release date) or we cut the spec from the release if that's possible. What this does is allow us to be honest about where we are and know a few weeks in advance if our release date is going to get pushed. From what I heard today, we're at least a month out and have not yet reached what I would call a freeze date (specs and TCKs are not yet frozen). Our release date is going to get pushed. Before we communicate a new timeline, we should decide two dates; a freeze date and subsequent release date.
|