https://bugs.winehq.org/show_bug.cgi?id=39744
--- Comment #21 from Nikolay Sivov bunglehead@gmail.com --- (In reply to Sebastian Lackner from comment #19)
(In reply to Nikolay Sivov from comment #18)
This https://packages.debian.org/stretch/wine shows 1.8-rc3.
Ah, thanks for pointing this out. I was looking at the "wine-development" package which used to be more up-to-date during the last year, but seems its now exactly the other way round? I'm wondering how users should stay up-to-date when they have to switch the package inbetween.
The logic is probably to name it 'wine' for stable releases, and 'wine-development' for biweekly releases.
Various autogenerated files (unicode tables, OpenGL extension tables, wineserver request tables) are regenerated during the build process, which potentially introduces new bugs / incompatibilities not present in official WineHQ builds.
That should not be a problem if they want to regenerate from Unicode data, as we depend on particular versions of those that don't change once released. But sure, there's no need to do that in practice.
I still see a high risk of introducing new problems. See for example the OpenGL tables, which are generated based on the XML files shipped in the "khronos-api" package. Last update is from March 2015, but in Wine we had a commit to update them in April for example.
Right, I can only speak about Unicode data files, because that's what I touched. If some files are not versioned and are constantly updated then it's a potential breakage. And actually now that I double checked not all Unicode data files are in versioned dirs, so this is affected too (not in practice because it's very unlikely they will ever update those).