Wine 7.0-rc1 Released With Last Minute Changes

[phoronix]

Phoronix: Wine 7.0-rc1 Released With Last Minute Changes

Following last week's Wine 6.23 development release, Wine 7.0-rc1 was just declared in marking the end of feature development and beginning preparations for issuing Wine 7.0.0 stable in January...

https://www.phoronix.com/scan.php?pa...x=Wine-7.0-rc1

[Danny3]

Not making it for Wine 7.0 is the FUTEX2/futex_waitv system call use for that functionality premiering in Linux 5.16 and the still-in-progress Wayland driver work.

Oh, come on, I hoped for at least one of them!
What's even the point of of changing the major version number without any major upgrade?

[mphuZ]

Phoronix: Wine 7.0-rc1 Released With Last Minute Changes

Following last week's Wine 6.23 development release, Wine 7.0-rc1 was just declared in marking the end of feature development and beginning preparations for issuing Wine 7.0.0 stable in January...

Waiting for another Steam Deck delay?

[tildearrow]

Oh, come on, I hoped for at least one of them!
What's even the point of of changing the major version number without any major upgrade?

Sadly, that's open-source. Linux, KDE Plasma and Wine do this (major version number is meaningless).

[smitty3268]

Sadly, that's open-source. Linux, KDE Plasma and Wine do this (major version number is meaningless).

All software does that. Strict versioning only really makes sense when it comes to libraries that other projects depend on.

[skeevy420]

And it sucks that there's no good solution. We end up with either version 1.2.43 or version 243 and, either way, there's 243 fuggin releases with 243 sets of fuggin release notes to read through to figure out what's what.

I prefer yyyy/mm/dd date based versioning because at least I can glance at any package and figure out if it might be old or not. Like, why TF is Mesa from May of 2019? You shouldn't be there.

[Nocifer]

Oh, come on, I hoped for at least one of them!
What's even the point of of changing the major version number without any major upgrade?

I think it's always been pretty much a given that the Wine devs won't mainline futex_waitv support until at least the 5.16 kernel is released.

[shmerl]

Code freeze is more of a problem than any version bump. It means new features will flow in with delay. I.e. whatever the version number is less important than timely updates. Ideally things should move in gradually without any freezes.

[oiaohm]

Oh, come on, I hoped for at least one of them!
What's even the point of of changing the major version number without any major upgrade?

Sadly, that's open-source. Linux, KDE Plasma and Wine do this (major version number is meaningless).

All software does that. Strict versioning only really makes sense when it comes to libraries that other projects depend on.

All three of you there is answer. Winelib can be used by external projects so that does answer smitty3268.

Wine major version number change and the stable release is the time of year the wine project stops development and totally focuses on quality assurance. You know those minor bugs that collected up over 12 months that no one has bothered fixing.

Different projects have different reasons for major version number changes. Wine major version is really linked to code quality than feature upgrade. Feature upgrade is to happen in the development branches releases that could be questionable quality.