> 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.
First of all I would like to know what you mean by features.
As I noted in previous mails, all API:s that doesn't
follow the documentation are buggy and fixing them,
unless a large restructuring is needed, which is almost
never the case, do not add any new features by
my defintion of feature.
> 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.
What is your definition of a bug fix?
> 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.
Agreed. But exactly how should we maintain the stable version?
There are serveral possibillities as I and Ove briefly discussed
and in addition we could treat the core dlls and the non-core dlls
diffrently.
> * some kind of automated regression testing, at least for
> non-graphical APIs
This would be nice. It has been on my TODO list for quite
some time, it haven't had high enough priority to ever
get started though.
One simple thing that easily could be done is to use
the spec files and generate NULL pointer tests with
exception handlers and return checks and run it
under Wine and Windows and compare the results.
Perhaps we could at least get some more applications
stop crashing. Just an idea...
> 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.
Yes, this is definitely a post 1.0 item, this is both
non-trival and theoretically impossible for emulated
application eventhough many emulated applications
probably will work. It would be nice for WineLib
applications though.
