Wine 1.0 coming soon

[sedwards]

Hello,
I wanted to let everyone know that Wine 1.0 will hopefully be released in about 2 months and we are coming up on a hard code freeze in the next 23 days. Now would be a good time for you to try out optimizations and profiling of your favorite Windows games and applications to see if we can find any bottlenecks. Please take some time and give a recent Wine git snapshot a try and if you discover any area that needs a performance enhancement, file a bug report on http://bugs.winehq.org and send a detailed email to the wine-devel mailing list describing the affected code and your proposed solution. Patches are always welcome!

Thanks
Steven

[PEETIE]

Is all coding going to stop abruptly on wine after 1.0 in this "code freeze", or will there be an unstable branch? It would be a shame to see all progress stop in wine while Windows 7 barrels ahead with new code and wine falls behind. Is the code freeze for a set amount of time? What happens to the SOC projects while wine is in "code freeze". What's the big deal about 1.0? It's just a vacuos release number, it's not like between now and 23 days everything is going to start working in wine that doesn't. I still can't even play most of my older games in wine. I think it should have been wine 95, 98, 2000, XP, etc. and release a new one when you reach compliance with a version of windows. Why stop the work, innovation, and progress for a release number and put a wart on the ass of progress with a "code freeze".

[timeBandit]

OK, you've made quite a few negative assumptions there from a key misinterpretation, so allow me to shed some light. In the parlance of software development, a "code freeze" is not a permanent condition and rarely even a prolonged one. It's simply a period beginning some time before and ending soon after a chosen release date, during which developers agree (or are enjoined) not to commit changes to the code base. Usually this period is brief, on the order of days or weeks.

A code freeze is often imposed at the start of a pre-release enhancement and regression test cycle. Otherwise, as testing progresses, changes to already-tested features (or, worse, introduction of brand-new features) might introduce new bugs that go undetected. During such a freeze, changes are accepted only if they correct bugs reported in post-freeze testing.

A "hard freeze" is typically even more strict: no changes at all are accepted during the freeze, on the theory that critical bugs should be fixed by that late date. This type is often imposed on larger projects, when preparation and packaging of a release is itself a big job. It's just a way to ensure you know what you're releasing, no surprises.

Notice I didn't mention a version number. It doesn't matter what you label the release, a freeze is just a step in one type of development cycle. Code freezes usually end soon after the release and normal development resumes.
_________________
Plants are pithy, brooks tend to babble--I'm content to lie between them.
Super-short f.g.o checklist: Search first, strip comments, mark solved, help others.

[dmead]

dear steven,

please get steam games working again


love dan

[bunder]

[rgk]