The development release Wine 10.19 is out now for the compatibility layer that powers Valve's Proton, here's all that's new and improved.

The development release Wine 10.19 is out now for the compatibility layer that powers Valve’s Proton, here’s all that’s new and improved. Early next year we should see Wine 11, and then at some point Proton 11 too!

From the highlights:

Support for reparse points.

  • More support for WinRT exceptions.
  • Refactoring of Common Controls after the v5/v6 split.
  • Typed Arrays support in JScript.
  • Various bug fixes.
    • cecilkorik@lemmy.caEnglish
      11·
      16 hours ago

      It means you can basically run even more Windows programs on Linux than you already can, and that’s wonderful. At the rate it’s going, soon Wine and Linux will be more compatible with Windows software than Windows itself is. Especially older stuff.

  • palordrolap@fedia.io
    82·
    23 hours ago

    Odd question: What would be the fallout from changing the version numbering to be more like the change recently made by LibreOffice? That is, making it be related to the year number rather than the current system.

    The reason I ask is that Linux has been and will be getting refugees from Windows 10 and 11, and the timing of the current version numbers is somewhat unfortunate and potentially confusing in that regard.

    I’m aware I may be imagining a problem that won’t actually exist in any meaningful amount.

    There’s also the potential problem of Microsoft following suit with whatever follows Windows 11 being “Windows 2029” or something, but it wouldn’t be too hard to deliberately throw in another jump if that were to happen at the loss of some synchronicity.

    Wine 49 certainly has a ring to it!

    • Prove_your_argument@piefed.socialEnglish
      3·
      22 hours ago

      Hard agree on versioning systems including the year. Model year is fine, or just the year.

      So Wine 2025-10.19 or something now…

      Wine 2026-11.x later?

      • palordrolap@fedia.io
        1·
        12 hours ago

        I wouldn’t want to keep the 11 in there. The entire reason for (hypothetically) making this change is to get away from the old version number and any potential confusion it might cause.

        I also prefer smaller version numbers, so “subtract 2000 from year” works better for me (and there’s no better time to take advantage of the fact this produces sensible numbers), but I can see why the full year might be preferable for someone else.

        • Prove_your_argument@piefed.socialEnglish
          2·
          7 hours ago

          How do you differentiate between significant major releases from a minor patch that just happens to release in Jan 1st? Use old year versioning?

          • palordrolap@fedia.io
            1·
            3 hours ago

            Yeah. I think I have a preference for a three tier system that’s Y.R.P (e.g. 25.0.2; “Year”, Release within year, Patch number), so yes, I could imagine the third level being incremented the following year in an emergency.

            And if two-tier is paramount, tricks like (R+1)*100+P will work provided there aren’t going to be 100 patches per release. (e.g. 25.102)