I think we definitely want to make a 1.0 release. Not because of
marketing reasons, but because our end goal is an emulator that works
for everybody, not only for developers; and this will require at some
point that we stop adding features and concentrate for a while on
stabilizing the code.
The release process I envision would be like this: once all the
features that we want in 1.0 are in place, I'll make a 0.9 release
which marks the feature freeze; from then on, only bug fixes will be
allowed into the tree, until we consider it stable enough to call 1.0.
There will _not_ be a separate unstable branch until after 1.0 is out;
otherwise developers will continue working on the unstable branch and
the bugs won't get fixed.
As to the features we want in 1.0, here is my personal list:
* (surprise) address space separation
- NT-like WOW VDMs for Win16 processes
- dll shared sections
- if possible no system structures allocated on the system heap
* better window management
- update regions calculation will get broken by address space
separation
- rewrite of -managed mode support
* correct interfaces between dlls
- dlls only use exported APIs
- no more global variables
- functions exported from libwine.so reduced to a minimum
- proper separation of GDI and USER
* backwards compatibility
- an app built against Winelib 1.0 should work with Wine 1.1 dlls
- the other way around is not necessary (i.e. if you upgrade an
app/dll you may have to upgrade the Wine core too)
* thread-safe GDI (merge from Corel tree)
* a set of "certified" applications that work correctly
- all apps based on InstallShield should at least get installed right
* some kind of automated regression testing, at least for
non-graphical APIs
* better font handling would be nice, but this depends a lot on the X
server, so it may have to wait until more infrastructure is in place
The major point for the release after 1.0 should IMO be a better
desktop integration by making it possible to use a standard toolkit;
ideally a modular toolkit interface, but even support for only a
single toolkit (probably GTK) would be good enough.
--
Alexandre Julliard
[EMAIL PROTECTED]
