2008/9/25 Michael Phipps <michael.phipps@xxxxxxxxxxx>: > Not to stir the pot, but since we were asked to discuss... At least you're getting discussion started :) > Setting a release date is *not* a good idea. Think about all of the press > that you will get. Slashdot, osnews, reddit, etc. Then, if it doesn't happen > (for whatever reason...)? Yikes! I learned early on that "when it is done" is > the best of all possible answers. Well to be fair - it was *not* a "release date" but rather a "freeze date" - which should instead imply a "code-freeze" I believe at which might imply no new functionality being added, no refactoring of existing issues, simply testing and bugfixing in preparation for the real release. I didn't vote on this proposition because it's really something that the core devs need to decide on themselves. I seriously do think setting a freeze date that all devs will adhere to is a good idea, at least until alpha is "out the door" and the next alpha/beta is in the works. Without setting some sort of freeze date, you're essentially leaving the alpha release open-ended, and it may never happen. For an alpha, I would maybe consider adopting a slightly different strategy: "If it's not done by the time we ship it, then that's too bad."... I realize that's an unpopular opinion, but I think this Alpha needs to happen soon. We've already agreed to the blockers - but if nobody adopts the blockers, and they don't ever get finished, there won't ever be an Alpha... For everyone's benefit, I will copy the proposition as it currently reads below: ------------------------------ Prop # 7: Set a preliminary freeze date for alpha 1 Adopted by: nielx Set a date on which the source repository is freezed and where alpha 1 will be finished. Status: Pending (5 against 5) In favour: nielx, dlmcpaul, leavengood, scottmc, mauricek Against: mmlr, bonefish, stippi, axeld, sikosis ------------------------------ - Urias