On 09/12/2010 06:36 AM, Dan Kegel wrote:
Looks like Alexandre must have fired up his time machine again :-)
And as long as it's up and running, how about a look forward at the 1.4 release plans?
I've discussed this idea with a lot of (non-Wine-Developer) stake-holders, and a few things came up pretty consistently.
1) Have some sort of time limit for the freeze process to start. Specific features are great for a release, but recognize that Wine gets dozens of features every month in the form of bug fixes and new applications working. Add enough of them together and you have something worthy of a release even without one big thing in particular.
2) That said, there are a few big things that would be great as release goals in and of themselves. That means substantial effort to include and polish them on behalf of core Wine developers, followed by a freeze. Possible features to name here have already been listed by others and in the wiki - DIB engine, Direct3D 10, OpenAL audio, etc.
3) Instead of a software developing perspective, we could instead release based on a QA perspective. This would mean ignoring which features were ready (or almost ready) and instead focus on the QA metrics we have - make the test suite pass everywhere (and on Windows), make sure we have some metric of test coverage, make sure the number of nonworking apps hasn't increased in some time, and so on.
These ideas can all be combined, eg we don't freeze unless we have a big feature OR a whole year has passed, and once we freeze we don't release until the test suite passes on Windows, Linux, and Mac.
Thanks, Scott Ritchie