It's perfectly fine how you have done it in your last report for Limbo (when I consider that rc version as stable as it's very unlikely that the final release will suffer from regressions compared to it). I'm happy with that. Thanks!

The stable version of Wine has a much longer life span than any development or otherwise patched Wine version and is less prone to regressions, so test results for the stable version are much more valuable. Only when a game does not run with the stable version test results for development or patched Wine versions are more interesting, at least for me.

I don't think adding another version number in that line impacts readability. And how's that information redundant? A test result for the development version of Wine already can be invalid a few weeks later while the test result for the stable version usually is valid for a much longer time.

Reports on WineHQ are mostly not for the GOG version of a game and the GOG version often differs in behavior from other versions. So for GOG games this thread is much more helpful than WineHQ.

CSMT is still quite experimental and involves huge changes. It's still only in wine-staging, I don't think it will be included in regular wine in the near future, or maybe ever. It actually was dropped from wine-staging 1.9.6 and reintroduced in 1.9.10, because of some incompatibility issues, or something. So, not stable vanilla Wine material.

I'll also add that a lot of them are very poorly written, with almost no useful information as to how a game fails on a given WINE version. Many of them also were written for 1.1.x-1.3.x builds or earlier, at least for classic games.

Personally, I think that line in your LIMBO entry looks dumb. I'm halfway tempted to have it a requirement to have only one for the version field (that being whichever had primary testing done with it). I have no issues with it being mentioned down in the install section/notes. In fact that usually useful as I already mentioned.
As far as readability, just expect to hear some whining if a report has 4 different Wine versions in it. Depending on how it's presented.

You are wrong about Wine Staging by the way. It has been an official part of the Wine project for some time now. The Staging folks are actually the ones who build the official WineHQ packages (both vanilla & staging versions).


That's part of what I was trying to say.

Thanks. I would have mentioned this had I noticed it. That's included in inxi -SG output, but I realize you may not have that installed.

I'm not interested in the branch of Wine. The specific version used is the requirement. That suffers from no regressions. I have no problem for anyone who tests with 1.8.x, but they would need to be exact.

It looks dumb there. It's redundant because it can assumed to be the same. If it's different than it would be required to specify which version.

You do realize I created the thread, yes? Not to mention the "ratings" I assign to the AppDB reports. This thread however is not going to attempt to track all tests for all versions of Wine for a given game. The forum software is completely unsuited to it, and the AppDB site is specifically designed with that in mind.

Oh, there is nothing stopping anyone from submitting a test on AppDB with all useful information included. Again for anyone who might be interested in doing so.
It did not make it in before the code freeze. Whatever is left, which is not insignificant, would be considered new features. No, in other words.

I think you're maybe overreacting a bit. :D
What's the difference between mentioning it in the info list and in the details? I can't see anyone interested and capable enough to try to install the Windows version of a GOG game on Linux whining about the confusing versions...

As far as CSMT is concerned, I was talking about the wine and wine-staging packages, not the project, which was the question, if I'm not mistaken. :)

I want the version it was tested with. Not the one you tested for half a minute and the game happened to successfully load. Now for some that may be the same if you didn't do more than install it and run around for a second. Otherwise the version with the most playtime is more valuable. Mentioning the e.g. vanilla 1.9.27 is likely useful. It does not have the same prominence however.

I was actually speaking of both the project & packages. If you have access to Wine HQ packages you have access to wine-staging packages. Also, while CSMT is a significant patch, staging has many other fixes in it. Not all of which are complete.

Edit: In case I haven't been expressing myself clearly I'm not telling people to go over to the AppDB instead of posting in here. This thread however is not trying to replicate the AppDB's multi-Wine, multi-testing abilities. The format does not support that in any elegant fashion vs the site which does. I'm also not all that spun up about it all.

Sorry, I haven't been clear enough. I also would like to have test results for exact versions. That's why I wasn't very happy with the "older and non-staging versions work fine as well". But when a game works with one of the stable releases of Wine it is very likely that it also works with any subsequent release from the stable branch while that may not be true for releases from a development branch. That's why I prefer test results for stable releases.

When a game runs with a staging or CSMT version of Wine I wouldn't expect that it also always runs with the same vanilla version of Wine. At least that's my experience.

I do. Your thread, your rules. :) This wasn't meant as an argument, just my opinion. I'm very happy that this thread exists at all, and would like to thank everyone who's contributing to it, especially you!

It's not that there are no good reports on WineHQ. But the average quality level of the reports is much lower than it's here, thanks to the good testers and the refining of the reports due to the interaction between testers and you.

How about a specific section about the Wine versions tested?

For example:

Wine version(s) tested:
wine-staging (with CSMT) 2.0rc3-1: Played for about 20 hours, works perfect.
wine 2.0rc3-1: Starts fine, walked around a bit, no further testing beyond that.

It's not optimal of course, but clearly states what was mainly tested and in which way.

Obviously it's fine to only have staging 2.0-rc3 for the version and mention in the notes that wine 2.0-rc3 appears to work. If you want to go to that level of detail though I think that does work well. Thanks.

Hmm, I noticed that The Witcher 2 isn't mentioned. I'm sure that I've played it from start to finish on wine, but have no idea what version of wine or what overrides I might have used, or if there were any issues involved.

Well, GOG offers a Linux version of The Witcher 2... which is just using a Wine wrapper, if I'm not mistaken.

That came later, I'm sure I played it on wine. But maybe it's not that interesting given the port.

Witcher 2's Linux version is not Wine-Wrapped, it's using Virtual Programming's 'eON' translation layer. While some may argue whether it's a wrapper or not, the end result is that it's better than Wine and it can run DX11 games (BioShock Infinite is a good example of this).

Really?! I didn't know that, very interesting. I think I'll give it a try then.