February 2026 - Wine-Devel - list.winehq.org

Re: Submitting patches to staging

by oosakadayoh＠gmail.com

It seems odd that no one has taken the bother to actually submit this under their name, but: I really want this to be upstreamed. Like, a lot. My job requires me to have a functioning (even if offline) copy of MCBE working on my machine, and so far this has been the only solution that makes it possible. However, updating Wine and WineGDK is an absolute pain and bother, so I would really like for this to be upstreamed. I assume someone else probably is already willing to give their real name to submit this, but in the remote chance no one actually stepped up and gave the name, I'm absolutely willing to use my name to get this upstreamed. I don't care to take recognition, the work LightGray has done is godsent and I would never in a hundred years get to that level. I wanna do this purely to get this upstreamed and for the convenience of my workplace. And also, I feel like the Deck is almost *made* for MCBE. We're sitting on gold here, I really want this to be upstreamed. I'm willing to be actively (or passively) involved in future patches as well if it means getting MCBE to work on my machine with sudo dnf install wine... Genuinely would be a game changer. Thanks

Feb. 26, 2026

Re: Wine for GDK apps, to upstream or to not upstream, that is the question.

by Alistair Leslie-Hughes

This was previously discussed here. https://list.winehq.org/archives/list/wine-devel@list.winehq.org/thread/THA… Best Regards Alistair On 2/25/26 13:56, oosaka dayo via Wine-devel wrote: > Recently came across a repo that patches wine with the modules required > to run first party GDK apps. Upstreaming it would be a huge gain for the > gaming space, Minecraft is by far the biggest game on the planet, and > most of the user base is on BE/PE. I've tried it and the patches work, > there's work to be done, none of the online services work yet, but it's > way better than any of the alternatives, and has been my goto for McBE. > Updating wine every time is a bit of a hassle though, considering how > the project doesn't even use wine as a submodule, rather the author > manually down streams the changes every oh so much... > > Re: Upstreaming > The current issue is: the developer of the project doesn't wanna > upstream it cause of anonymousity, which I understand, but it's a huge > miss, considering how this change could also be easily down(up?)streamed > to proton and such, where it would really help (McBE on Deck would be > the perfect match); > So, I'm not sure how to move from here, I'd really like the patches to > be upstreamed, but I'm not sure who can do it or how. The code that's > been changed is public license, per the author's readme... > > How do you think it's gonna be approached? > Thanks, > Dave > > P.S. Yes currently there is no clean way to obtain the game's decrypted > executable, I got mine because of my job, but it's not publicly > available yet. Either way, we'll cross that bridge when we get there...

Feb. 25, 2026

Wine for GDK apps, to upstream or to not upstream, that is the question.

by oosaka dayo

Recently came across a repo that patches wine with the modules required to run first party GDK apps. Upstreaming it would be a huge gain for the gaming space, Minecraft is by far the biggest game on the planet, and most of the user base is on BE/PE. I've tried it and the patches work, there's work to be done, none of the online services work yet, but it's way better than any of the alternatives, and has been my goto for McBE. Updating wine every time is a bit of a hassle though, considering how the project doesn't even use wine as a submodule, rather the author manually down streams the changes every oh so much... Re: Upstreaming The current issue is: the developer of the project doesn't wanna upstream it cause of anonymousity, which I understand, but it's a huge miss, considering how this change could also be easily down(up?)streamed to proton and such, where it would really help (McBE on Deck would be the perfect match); So, I'm not sure how to move from here, I'd really like the patches to be upstreamed, but I'm not sure who can do it or how. The code that's been changed is public license, per the author's readme... How do you think it's gonna be approached? Thanks, Dave P.S. Yes currently there is no clean way to obtain the game's decrypted executable, I got mine because of my job, but it's not publicly available yet. Either way, we'll cross that bridge when we get there...

Feb. 25, 2026

Re: Wine staging 11.3 release

by Elizabeth Figura

On Monday, 23 February 2026 03:24:03 CST Alois Schlögl via Wine-devel wrote: > I'm sure some of the patches would be difficult to handle. I'm just > wondering why "fonts-Missing_Fonts" is not upstreamed yet, it seems > simple, and a lot of applications would benefit from this. A brief > review of the license terms does not show any red flags to me. What > needs to be done to get these in ? The fact that the license is different at all is concerning. I haven't tried to submit it yet, but it gives me the vibes of being a thorny case, and I try to at least space those out so as to not overwhelm Alexandre with hard problems. Currently I think there's still more work to do on reparse points, and then after that I was planning to work on a category of problems related to device paths, which also touches very low level code and has the potential to be thorny. > More general speaking, there are many patches that seem simple, and have > a reference to a bug report that is (supposedly) fixed by that patch, > but it is not clear what the problem with those patches are (I just > checked msi-cabinet, mountmgr-DosDevices, wine.inf-Dummy_CA_Certificate > ). A list of review status, of each patch set, could be beneficial to > share the workload. e.g. > - no reviewed > - no ready for upstream/needs more work > - missing tests > - should be considered by upstream I think in most cases it really is just a matter of someone needing to take the time and effort to look into it. Some patches aren't even "hard" per se, honestly; they're just areas that I'm still not familiar with and so I'd need to do a bunch of research to understand what the patch is doing. Many patches really just need a ruling from an upstream maintainer, which has often been very hard to get, although to give credit I've had an easier time recently. Some patches are also written by an active contributor, and so I tend to not look at those on the theory that that contributor will submit them upstream themselves at some point. Granted, some have been here for years... That said, in some cases there are known problems that could be publicly documented. I'll start working on describing some of the known problems with patches and putting them in the "definition" files, which is where some that information already goes. As for the ones you specifically called out: * msi-cabinet I think just needs a test. * mountmgr-DosDevices could use a test, and investigation of whether this is the correct path to write. It's also something I was going to look at while working on device paths, as well as ntdll-NtDevicePath and ntdll-NtQueryVirtualMemory. * wine.inf-Dummy_CA_Certificate is probably just the wrong way to solve this problem, but I don't know. Likely we should add a real certificate. > I understand also that reviewing patches of others takes some effort. > And accepting patches that you (and other maintainers) are not > comfortable with (i.e. increasing technical debt) is a really issue, > too. In cases when you do not have a hard reason to reject a patch set, > you could accept it (perhaps limiting this to one per release cycle), > and check only afterwards whether some problems pop up - the automated > tests as well use user feedback seems powerful enough to handle this. > This could really help to reduce wine-staging patch sets. I think the problem that's not really evident to people—and the reason that wine-staging was never as helpful as people thought—is that "testing" is very rarely what patches lack. I think at this point, the average wine-staging patch set is less likely to cause regressions than many patches that are committed upstream. Patches that have a hard time going upstream are almost always stuck because they're architecturally ugly, and committing them would introduce a maintenance problem, or because they're simply architecturally *wrong* and would need to be redone from scratch at some point. That's not something that being in wine-staging can really fix, and I doubt it ever could. The people who are reviewing patches in wine-staging at this point (i.e. mostly just me) are also reviewing patches upstream. --Zeb

Feb. 23, 2026

Re: Wine staging 11.3 release

by David Kahurani

You gonna teach me how to do this? On Mon, Feb 23, 2026 at 12:34 PM David Kahurani <k.kahurani(a)gmail.com> wrote: > > On Mon, Feb 23, 2026 at 12:24 PM Alois Schlögl <alois.schloegl(a)gmail.com> wrote: > > > > > > > > Am 22.02.26 um 8:02 PM schrieb Elizabeth Figura via Wine-devel: > > > On Saturday, 21 February 2026 01:45:41 CST David Kahurani via Wine-devel wrote: > > >> On Sat, Feb 21, 2026 at 6:07 AM Alistair Leslie-Hughes via Wine-devel > > >> <wine-devel(a)list.winehq.org> wrote: > > >>> Binary packages for various distributions will be available from: > > >>> https://www.winehq.org/download > > >>> > > >>> Summary since last release > > >>> * Rebased to current wine 11.3 (241 patches are applied to wine vanilla) > > >>> > > >>> Upstreamed (Either directly from staging or fixed with a similar patch). > > >>> * mshtml: Add IXMLSerializer implementation. > > >>> > > >>> Removed (No longer required). > > >>> * None > > >>> > > >>> Added: > > >>> * None > > >>> > > >>> Updated: > > >>> * vkd3d-latest > > >>> > > >>> > > >>> Where can you help > > >>> * Run Steam/Battle.net/GOG/UPlay/Epic > > >>> * Test your favorite game. > > >>> * Test your favorite applications. > > >>> * Improve staging patches and get them accepted upstream. > > >>> * Suggest patches to be included in staging. > > >>> > > >>> As always, if you find a bug, please report it via > > >>> https://bugs.winehq.org > > >> It really doesn't look like you're doing much ;-( > > > I'm afraid that fixing and upstreaming a wine-staging patch is a lot of work. Neither Alistair, Paul, nor I has a lot of free time in which to do that work, and I can say that I at least have a lot less free time than I used to for various reasons. To make matters worse, compared to seven years ago, the patches that are left in wine-staging are the harder ones, taking a lot more effort to understand and rewrite. We took care of most of the easy ones first. > > > > > > I've been working on rewriting inseng-Implementation, which is a difficult task; it's a 3500 line diff that needs to be properly split (I'm anticipating dozens of patches by the time I'm done), needs tests added (it has none, and pretty much everything in inseng can in fact be tested); the INF parsing stuff should almost certainly be rewritten on top of setupapi (I don't know why Michael wrote a custom parser), and I need to see if the urlmon stuff can be redone on top of an API that's less horrible than urlmon. I'm anticipating the whole thing will take me a couple more months at the current pace. > > > > > > Meanwhile, I just got done implementing reparse points upstream, a month-long effort if you don't count the regressions (or the Unix symlink support, which isn't done either), and ntsync, a project that started in late 2020. And in both cases I was lucky enough to be able to spend actual work hours on them. Most wine-staging patches aren't anything that CW's clients care about. inseng certainly isn't. > > > > > > The goal of Wine-Staging since we took over maintainership was supposed to be a restoration of its original stated goal—to provide a place where patches not ready could be tested and incrementally improved, then submitted. But fundamentally Alistair and I were first and foremost rescuing the project, and we never had the time to execute this goal like it perhaps deserved. Not to mention that the "incremental" part ends up kind of being a waste of time—it's far less time-consuming to just look at a patch, fix everything wrong with it at once, then submit it upstream directly. > > > > > > At this point I'm almost the only one working on wine-staging patches, so frankly, hearing anyone complain about the lack of progress is a little frustrating. If you'd like to see more progress I would beg you to upstream wine-staging patches yourself. (Critically, that doesn't just mean taking a patch and throwing it upstream. Patches are in wine-staging for a reason, and they need to be improved first.) > > > > > > --Zeb > > > > > > > > > > I have probably over 20+ stale Linux patches, because no-one will take them. > > > I'm sure some of the patches would be difficult to handle. I'm just > > wondering why "fonts-Missing_Fonts" is not upstreamed yet, it seems > > simple, and a lot of applications would benefit from this. A brief > > review of the license terms does not show any red flags to me. What > > needs to be done to get these in ? > > > > More general speaking, there are many patches that seem simple, and have > > a reference to a bug report that is (supposedly) fixed by that patch, > > but it is not clear what the problem with those patches are (I just > > checked msi-cabinet, mountmgr-DosDevices, wine.inf-Dummy_CA_Certificate > > ). A list of review status, of each patch set, could be beneficial to > > share the workload. e.g. > > - no reviewed > > - no ready for upstream/needs more work > > - missing tests > > - should be considered by upstream > > > > I understand also that reviewing patches of others takes some effort. > > And accepting patches that you (and other maintainers) are not > > comfortable with (i.e. increasing technical debt) is a really issue, > > too. In cases when you do not have a hard reason to reject a patch set, > > you could accept it (perhaps limiting this to one per release cycle), > > and check only afterwards whether some problems pop up - the automated > > tests as well use user feedback seems powerful enough to handle this. > > This could really help to reduce wine-staging patch sets. > > > > > > --Alois

Feb. 23, 2026

Re: Wine staging 11.3 release

by David Kahurani

On Mon, Feb 23, 2026 at 12:24 PM Alois Schlögl <alois.schloegl(a)gmail.com> wrote: > > > > Am 22.02.26 um 8:02 PM schrieb Elizabeth Figura via Wine-devel: > > On Saturday, 21 February 2026 01:45:41 CST David Kahurani via Wine-devel wrote: > >> On Sat, Feb 21, 2026 at 6:07 AM Alistair Leslie-Hughes via Wine-devel > >> <wine-devel(a)list.winehq.org> wrote: > >>> Binary packages for various distributions will be available from: > >>> https://www.winehq.org/download > >>> > >>> Summary since last release > >>> * Rebased to current wine 11.3 (241 patches are applied to wine vanilla) > >>> > >>> Upstreamed (Either directly from staging or fixed with a similar patch). > >>> * mshtml: Add IXMLSerializer implementation. > >>> > >>> Removed (No longer required). > >>> * None > >>> > >>> Added: > >>> * None > >>> > >>> Updated: > >>> * vkd3d-latest > >>> > >>> > >>> Where can you help > >>> * Run Steam/Battle.net/GOG/UPlay/Epic > >>> * Test your favorite game. > >>> * Test your favorite applications. > >>> * Improve staging patches and get them accepted upstream. > >>> * Suggest patches to be included in staging. > >>> > >>> As always, if you find a bug, please report it via > >>> https://bugs.winehq.org > >> It really doesn't look like you're doing much ;-( > > I'm afraid that fixing and upstreaming a wine-staging patch is a lot of work. Neither Alistair, Paul, nor I has a lot of free time in which to do that work, and I can say that I at least have a lot less free time than I used to for various reasons. To make matters worse, compared to seven years ago, the patches that are left in wine-staging are the harder ones, taking a lot more effort to understand and rewrite. We took care of most of the easy ones first. > > > > I've been working on rewriting inseng-Implementation, which is a difficult task; it's a 3500 line diff that needs to be properly split (I'm anticipating dozens of patches by the time I'm done), needs tests added (it has none, and pretty much everything in inseng can in fact be tested); the INF parsing stuff should almost certainly be rewritten on top of setupapi (I don't know why Michael wrote a custom parser), and I need to see if the urlmon stuff can be redone on top of an API that's less horrible than urlmon. I'm anticipating the whole thing will take me a couple more months at the current pace. > > > > Meanwhile, I just got done implementing reparse points upstream, a month-long effort if you don't count the regressions (or the Unix symlink support, which isn't done either), and ntsync, a project that started in late 2020. And in both cases I was lucky enough to be able to spend actual work hours on them. Most wine-staging patches aren't anything that CW's clients care about. inseng certainly isn't. > > > > The goal of Wine-Staging since we took over maintainership was supposed to be a restoration of its original stated goal—to provide a place where patches not ready could be tested and incrementally improved, then submitted. But fundamentally Alistair and I were first and foremost rescuing the project, and we never had the time to execute this goal like it perhaps deserved. Not to mention that the "incremental" part ends up kind of being a waste of time—it's far less time-consuming to just look at a patch, fix everything wrong with it at once, then submit it upstream directly. > > > > At this point I'm almost the only one working on wine-staging patches, so frankly, hearing anyone complain about the lack of progress is a little frustrating. If you'd like to see more progress I would beg you to upstream wine-staging patches yourself. (Critically, that doesn't just mean taking a patch and throwing it upstream. Patches are in wine-staging for a reason, and they need to be improved first.) > > > > --Zeb > > > > > I have probably over 20+ stale Linux patches, because no-one will take them. > I'm sure some of the patches would be difficult to handle. I'm just > wondering why "fonts-Missing_Fonts" is not upstreamed yet, it seems > simple, and a lot of applications would benefit from this. A brief > review of the license terms does not show any red flags to me. What > needs to be done to get these in ? > > More general speaking, there are many patches that seem simple, and have > a reference to a bug report that is (supposedly) fixed by that patch, > but it is not clear what the problem with those patches are (I just > checked msi-cabinet, mountmgr-DosDevices, wine.inf-Dummy_CA_Certificate > ). A list of review status, of each patch set, could be beneficial to > share the workload. e.g. > - no reviewed > - no ready for upstream/needs more work > - missing tests > - should be considered by upstream > > I understand also that reviewing patches of others takes some effort. > And accepting patches that you (and other maintainers) are not > comfortable with (i.e. increasing technical debt) is a really issue, > too. In cases when you do not have a hard reason to reject a patch set, > you could accept it (perhaps limiting this to one per release cycle), > and check only afterwards whether some problems pop up - the automated > tests as well use user feedback seems powerful enough to handle this. > This could really help to reduce wine-staging patch sets. > > > --Alois

Feb. 23, 2026

Re: Wine staging 11.3 release

by Alois Schlögl

Am 22.02.26 um 8:02 PM schrieb Elizabeth Figura via Wine-devel: > On Saturday, 21 February 2026 01:45:41 CST David Kahurani via Wine-devel wrote: >> On Sat, Feb 21, 2026 at 6:07 AM Alistair Leslie-Hughes via Wine-devel >> <wine-devel(a)list.winehq.org> wrote: >>> Binary packages for various distributions will be available from: >>> https://www.winehq.org/download >>> >>> Summary since last release >>> * Rebased to current wine 11.3 (241 patches are applied to wine vanilla) >>> >>> Upstreamed (Either directly from staging or fixed with a similar patch). >>> * mshtml: Add IXMLSerializer implementation. >>> >>> Removed (No longer required). >>> * None >>> >>> Added: >>> * None >>> >>> Updated: >>> * vkd3d-latest >>> >>> >>> Where can you help >>> * Run Steam/Battle.net/GOG/UPlay/Epic >>> * Test your favorite game. >>> * Test your favorite applications. >>> * Improve staging patches and get them accepted upstream. >>> * Suggest patches to be included in staging. >>> >>> As always, if you find a bug, please report it via >>> https://bugs.winehq.org >> It really doesn't look like you're doing much ;-( > I'm afraid that fixing and upstreaming a wine-staging patch is a lot of work. Neither Alistair, Paul, nor I has a lot of free time in which to do that work, and I can say that I at least have a lot less free time than I used to for various reasons. To make matters worse, compared to seven years ago, the patches that are left in wine-staging are the harder ones, taking a lot more effort to understand and rewrite. We took care of most of the easy ones first. > > I've been working on rewriting inseng-Implementation, which is a difficult task; it's a 3500 line diff that needs to be properly split (I'm anticipating dozens of patches by the time I'm done), needs tests added (it has none, and pretty much everything in inseng can in fact be tested); the INF parsing stuff should almost certainly be rewritten on top of setupapi (I don't know why Michael wrote a custom parser), and I need to see if the urlmon stuff can be redone on top of an API that's less horrible than urlmon. I'm anticipating the whole thing will take me a couple more months at the current pace. > > Meanwhile, I just got done implementing reparse points upstream, a month-long effort if you don't count the regressions (or the Unix symlink support, which isn't done either), and ntsync, a project that started in late 2020. And in both cases I was lucky enough to be able to spend actual work hours on them. Most wine-staging patches aren't anything that CW's clients care about. inseng certainly isn't. > > The goal of Wine-Staging since we took over maintainership was supposed to be a restoration of its original stated goal—to provide a place where patches not ready could be tested and incrementally improved, then submitted. But fundamentally Alistair and I were first and foremost rescuing the project, and we never had the time to execute this goal like it perhaps deserved. Not to mention that the "incremental" part ends up kind of being a waste of time—it's far less time-consuming to just look at a patch, fix everything wrong with it at once, then submit it upstream directly. > > At this point I'm almost the only one working on wine-staging patches, so frankly, hearing anyone complain about the lack of progress is a little frustrating. If you'd like to see more progress I would beg you to upstream wine-staging patches yourself. (Critically, that doesn't just mean taking a patch and throwing it upstream. Patches are in wine-staging for a reason, and they need to be improved first.) > > --Zeb > > I'm sure some of the patches would be difficult to handle. I'm just wondering why "fonts-Missing_Fonts" is not upstreamed yet, it seems simple, and a lot of applications would benefit from this. A brief review of the license terms does not show any red flags to me. What needs to be done to get these in ? More general speaking, there are many patches that seem simple, and have a reference to a bug report that is (supposedly) fixed by that patch, but it is not clear what the problem with those patches are (I just checked msi-cabinet, mountmgr-DosDevices, wine.inf-Dummy_CA_Certificate ). A list of review status, of each patch set, could be beneficial to share the workload. e.g. - no reviewed - no ready for upstream/needs more work - missing tests - should be considered by upstream I understand also that reviewing patches of others takes some effort. And accepting patches that you (and other maintainers) are not comfortable with (i.e. increasing technical debt) is a really issue, too. In cases when you do not have a hard reason to reject a patch set, you could accept it (perhaps limiting this to one per release cycle), and check only afterwards whether some problems pop up - the automated tests as well use user feedback seems powerful enough to handle this. This could really help to reduce wine-staging patch sets. --Alois

Feb. 23, 2026

Re: Wine staging 11.3 release

by Elizabeth Figura

On Saturday, 21 February 2026 01:45:41 CST David Kahurani via Wine-devel wrote: > On Sat, Feb 21, 2026 at 6:07 AM Alistair Leslie-Hughes via Wine-devel > <wine-devel(a)list.winehq.org> wrote: > > > > Binary packages for various distributions will be available from: > > https://www.winehq.org/download > > > > Summary since last release > > * Rebased to current wine 11.3 (241 patches are applied to wine vanilla) > > > > Upstreamed (Either directly from staging or fixed with a similar patch). > > * mshtml: Add IXMLSerializer implementation. > > > > Removed (No longer required). > > * None > > > > Added: > > * None > > > > Updated: > > * vkd3d-latest > > > > > > Where can you help > > * Run Steam/Battle.net/GOG/UPlay/Epic > > * Test your favorite game. > > * Test your favorite applications. > > * Improve staging patches and get them accepted upstream. > > * Suggest patches to be included in staging. > > > > As always, if you find a bug, please report it via > > https://bugs.winehq.org > > It really doesn't look like you're doing much ;-( I'm afraid that fixing and upstreaming a wine-staging patch is a lot of work. Neither Alistair, Paul, nor I has a lot of free time in which to do that work, and I can say that I at least have a lot less free time than I used to for various reasons. To make matters worse, compared to seven years ago, the patches that are left in wine-staging are the harder ones, taking a lot more effort to understand and rewrite. We took care of most of the easy ones first. I've been working on rewriting inseng-Implementation, which is a difficult task; it's a 3500 line diff that needs to be properly split (I'm anticipating dozens of patches by the time I'm done), needs tests added (it has none, and pretty much everything in inseng can in fact be tested); the INF parsing stuff should almost certainly be rewritten on top of setupapi (I don't know why Michael wrote a custom parser), and I need to see if the urlmon stuff can be redone on top of an API that's less horrible than urlmon. I'm anticipating the whole thing will take me a couple more months at the current pace. Meanwhile, I just got done implementing reparse points upstream, a month-long effort if you don't count the regressions (or the Unix symlink support, which isn't done either), and ntsync, a project that started in late 2020. And in both cases I was lucky enough to be able to spend actual work hours on them. Most wine-staging patches aren't anything that CW's clients care about. inseng certainly isn't. The goal of Wine-Staging since we took over maintainership was supposed to be a restoration of its original stated goal—to provide a place where patches not ready could be tested and incrementally improved, then submitted. But fundamentally Alistair and I were first and foremost rescuing the project, and we never had the time to execute this goal like it perhaps deserved. Not to mention that the "incremental" part ends up kind of being a waste of time—it's far less time-consuming to just look at a patch, fix everything wrong with it at once, then submit it upstream directly. At this point I'm almost the only one working on wine-staging patches, so frankly, hearing anyone complain about the lack of progress is a little frustrating. If you'd like to see more progress I would beg you to upstream wine-staging patches yourself. (Critically, that doesn't just mean taking a patch and throwing it upstream. Patches are in wine-staging for a reason, and they need to be improved first.) --Zeb

Feb. 22, 2026

Re: Current wine-mono with older releases

by Esme Povirk

No. You would need at least two installable versions of the package: a stable release containing Wine Mono 10.4.1 (used by Wine 11.0) and a development release containing Wine Mono 11.0.0 (used by Wine 11.3). And since the versions may at some points be the same (meaning they need to install the same files), you would probably run into problems if they can both be installed at once. On 2026-02-21 14:06, Gerald Pfeifer via Wine-devel wrote: > Historically, for the FreeBSD ports of Wine and the Mono engine we have > frozen the latter at the time of a new release of Wine and used another > instance (usually newer at one point) for Wine' development snapshot. > > Is this actually necessary? > > Or could we just carry one Mono engine, at the latest and greatest > version, and use that both for the last Wine release (11.0 right now) > and Wine development snapshots (11.3 right now)? > > Is there a general answer, or is it "it depends"? > > Thanks, > Gerald >

Feb. 21, 2026

Current wine-mono with older releases

by Gerald Pfeifer

Historically, for the FreeBSD ports of Wine and the Mono engine we have frozen the latter at the time of a new release of Wine and used another instance (usually newer at one point) for Wine' development snapshot. Is this actually necessary? Or could we just carry one Mono engine, at the latest and greatest version, and use that both for the last Wine release (11.0 right now) and Wine development snapshots (11.3 right now)? Is there a general answer, or is it "it depends"? Thanks, Gerald

Feb. 21, 2026