Wine-1.0 release notes

[Reece Dunn]

2008/6/12 Vitaliy Margolen <wine-devel at kievinfo.com>:
> Reece Dunn wrote:
>>
>> 2008/6/11 Vitaliy Margolen <wine-devel at kievinfo.com>:
>>>
>>> In short - that after everyone's hard work and 15 years of development
>>> wine-1.0 is just a release tag nothing more.
>>
>> I think that this is overly harsh. It's like saying that you should
>> not celebrate a birthday, as that is just you aging just a day,
>> nothing more.
>
> If birthdays would start coming every 2 weeks after about 100's you will
> loose track and won't care anymore which one it is.

But those releases are beta releases. The issue here is not that Wine
does not have frequent releases - which it does - but that those
releases are beta. The perception and reception is different. Just
look at all the countless beta releases that Vista had and who was
using them; the majority of users didn't start using it until release.

>> Wine is in a strange position as it is trying to make any Windows
>> application (ultimately) run on any suitable posix system with a
>> suitable X server. Given that a new version of Windows is usually
>> released every 2-3 years, with new features, APIs and functionality,
>
> I wouldn't go that far. Win2k was released in ... 2000. XP (which has some
> number of additions over win2k) was release in 2003 with minor additions in
> 2004 and 2005. And no one in their right mind makes Vista only versions.
> That gives us what? 8 years.

2007 (Vista) - 2002 (XP release) = 5 years, not 8. Vista was an
exception to the release cycle that Microsoft had built since Win95.
Windows 7 is scheduled for 2009, which makes that another 2 years.
Excluding Vista, my statement holds.

> No this argument don't fly - not much is changing in the win32api world, or
> MS would risk killing all their legacy stuff - which is the only reason
> windows is still being used.

I was told that MS has added thousands of new native APIs. There are
the changes made to the theming code; the Desktop Window Manager (DWM)
API; the new hyperlink control; the extension of buttons to support
buttons with menus; the new file open/save API (which also has changes
to the way the Win2K-style open/save dialogs are detected, I believe);
the new enhanced message boxes; .... So saying that not much has
changed in Win32 (and COM) is wrong.

Also, look at the Wine test results to see that a fair amount of the
Win32 API have changed behaviour.

>> Yes, regressions will happen. Yes, applications will crash/fail to
>> work. But think of all the applications that *do* work; given what
>
> That's the problem. After identifying a regression it should be fixed.
> During the code freeze, the changes should be reverted, especially if this
> is new functionality that's having issues. And where were are with those? We
> have a big list of regressions introduced by major changes to different
> parts of Wine either right before the code freeze or during(!) the code
> freeze. And most of those regressions are still not dealt with.

So, like CodeWeavers, we need to pick a set of applications that we
can say "Yes, these *will* work with 1.0." Other applications *may*
work with 1.0 (and you'll need to look in the AppDB for your
particular application), but if they regress it will not block the
release of 1.0. Otherwise, you may as well not do a release, as the
mountain is impossibly steep.

> I'm not blaming anyone as I'm guilty creating regressions in the past.
> However the goal needs to shift from getting new features in, to stabilizing
> and bug fixing. And ~1 month for that is not enough, considering that it
> takes so long to fix some of the problems. I was really surprised to see
> _ANY_ new features getting into Wine in the last 2 months. Let alone major
> ones like XIM, child X windows, pixel formats.

So what new features have gone into RC1-4 (~2 months going on a 2 week
release cycle)?

The major features you mentioned went in before the freeze, IIRC, so
where is the problem? The regression that happened recently happened
because of a fix introduced to fix a game. Yes, it broke other games
(which I'd argue are good candidates for 1.0, so that particular
commit should be reverted cleanly), but we need to figure out which
games are important for 1.0. Another regression was the result of
cleaning up deprecated alsa calls that broke older alsa drivers on
various distributions (which I happened to spot - I thought it might
have been the pulseaudio adapter, but my machine is currently using a
real alsa driver).

Regressions happen. If they are in applications that we are going to
support in 1.0, they should be fixed, otherwise they should be in the
release notes if relevant

>> NOTE: I am not saying Wine is perfect, I'm saying that the message
>> should be positive and realistic instead of unduly negative.
>
> I did not meant to make it sound that negative. After all each new version
> of Wine had number of important features and loads of bug fixes. Which is
> great on it's own. Just don't make wine-1.0 anything more then it really is
> - new release with bug fixes and no new features.

The point of the freeze is *not* to add any new features. The point is
to address as many outstanding issues as possible, with minimal
regression. Unless (and until) Wine has a full and complete
implementation of the Windows API, then it does not stand a chance of
running every application flawlessly. So the release needs to be
pragmatic: which bugs are showstoppers, which applications does Wine
need to run.

Does anyone know what the state of installing/running Office 2003 is,
because I seem to recall there being a regression in this area. That
is something that I would consider a blocker.

- Reece