wxWidgets 3.1.2 was released back in December. While they call this a development release, they also say the following: " Please notice that while 3.1.2 is officially a “development” version because it is not fully compatible with the “stable” 3.0.x, the list of backwards incompatible changes is very short, so you shouldn’t have any problems updating to this version from 3.0.x in practice, and you’re encouraged to use this release, including in production. " I'm trying to properly package PrusaSlicer (which is a renamed and updated version of slic3r-prusa3d that's currently in the distro). That code much prefers to use version 3.1.2 of wxWidgets, and I'm having to carry a few patches to get it to work OK with 3.0.4. Are there any plans for moving to 3.1.2? I know it needs to be a big coordinated effort to deal with any incompatibilities but it's generally better to tackle those earlier rather than later.
(In reply to Jason Tibbitts from comment #0) > wxWidgets 3.1.2 was released back in December. While they call this a > development release, they also say the following: > > " > Please notice that while 3.1.2 is officially a “development” version because > it is not fully compatible with the “stable” 3.0.x, the list of backwards > incompatible changes is very short, so you shouldn’t have any problems > updating to this version from 3.0.x in practice, and you’re encouraged to > use this release, including in production. > " > > I'm trying to properly package PrusaSlicer (which is a renamed and updated > version of slic3r-prusa3d that's currently in the distro). That code much > prefers to use version 3.1.2 of wxWidgets, and I'm having to carry a few > patches to get it to work OK with 3.0.4. > > Are there any plans for moving to 3.1.2? I know it needs to be a big > coordinated effort to deal with any incompatibilities but it's generally > better to tackle those earlier rather than later. Historically, we haven't packaged the development/unstable releases (odd second digit), primarily because they do not guarantee API/ABI stability. However, upstream development (well, releases, specifically) has slowed down considerably to the point where it is rather unclear when a 3.2 release might occur. Yours is not the first request for this. Perhaps we could consider packaging 3.1.x alongside 3.0.x? I just managed to get rid of wx 2.8.x in Fedora a few months ago. :(
I understand about packaging development releases, except that upstream actually encourages that it be used in production. Whether the second digit is odd or not seems less material than what upstream says should or should not be used. Of course it's better if upstream is consistent in their terminology and methodology, but their statement seems unequivocal. I will admit to not having looked at the API incompatibilities; they indicate that they are small but don't really indicate what they are. And of course, there have been 871 commits since 3.1.2 was released so it's tough to say whether or not things are really slowing down. But if the breakage really is small then it might be possible to push an update to a side tag, try rebuilds of the relevant packages and fix things up. Of course, it's easy for me to say. And sure, certainly you could stick things in a parallel-installable package. Whether that's worth the maintenance overhead depends on how bad any breakage is. They sure seem to suggest that it's not bad at all.
I follow upstream fairly closely and I don't have doubts that 3.1.x is usable for production. It's just that there is no guarantee for API/ABI stability, so we'll have be doing rebuilds and possibly code adjustments after each 3.1.x release. A lot of the packages that depend on wx in Fedora barely compile with 3.0.x, so I'm not optimistic about general compatibility. wxPython, for one, is deeply tied to the internals of wx, so it certainly is not ready to work with wx 3.1.x. So, IMHO a parallel option is probably the only way to go.
Another option is to only update in rawhide. I.e. update rawhide to 3.1.2 now, then when 3.1.3 comes out, update rawhide to 3.1.3 and cherry-pick any security or any critical non-API changing bugfix patches back to the 3.1.2 builds that have made it into stable versions of Fedora (if applicable). This would give lots of time to rebuild/patch dependent packages but does have a downside of higher maintenance cost. If you follow upstream closely this /might/ be a lower maintenance option than parallel builds. I can't comment on ABI compatibility though as my knowledge of WX is very highlevel.
That second sentence is a bit confusing. Let me clarify. I see two possible options to preserve API compatibilty: 1. Add a parallel package: - Introduce a wxGTK31 package for tracking 3.1.* - Retire once 3.2 has been released 2. Keep rawhide version of wxGTK3 up to date: - Rawhide will track the latest "usable" WX version - Deal with breakage in rawhide before next release is branched - Backport any critical/security patches to stable release (avoiding API changes) Note: Proposal #2 does not consider ABI changes. At the end of the day, either solution works and they come with their own caveats.
Option #2 assumes that we'd be motivated / able to move all current wxGTK3 (3.0.x) users to wx 3.1 within one Fedora release cycle. I'm not very optimistic about this, given how long it took to get rid of wx 2.8, and the fact that a lot of wx-user packages in Fedora are poorly maintained, and I'm not a provenpackager, so the pull request process is SLOW and I end up having to beg a provenpackager to merge my pull requests after they get ignored. For #1, I was actually thinking about re-introducing the generic wxGTK package, and have it follow <master>. Then when wx 3.2 comes out, we could add a new package wxGTK32 that follows the 3.2.x maintenance stream, and wxGTK could continue to follow master.
Yeah, that seems like a fair solution, but I suggest posting your plan to the dev mailing list if you haven't done so already. Either way, I've changed you to an admin for the wxGTK git if that helps.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
So... I came to this after looking to get wxGTK3 into EPEL8, and now I'm wondering what the best course of action there would be. I'm guessing that packaging a "wxGTK3.0" for now would be the thing to do, since we aren't quite ready to do modules in EPEL8 yet. I would think that modules would be the way forward for Fedora though. I'm also wondering who is actually interested in maintaining wxGTK in EPEL8 as well.
(In reply to Orion Poplawski from comment #10) > So... I came to this after looking to get wxGTK3 into EPEL8, and now I'm > wondering what the best course of action there would be. I'm guessing that > packaging a "wxGTK3.0" for now would be the thing to do, since we aren't > quite ready to do modules in EPEL8 yet. I would think that modules would be > the way forward for Fedora though. I'm also wondering who is actually > interested in maintaining wxGTK in EPEL8 as well. I'm willing to maintain wxGTK3 (ie, equivalent or so to the current Fedora wxGTK3 package) in EPEL8. Do you mind filing a separate bug though? This one is more about the unstable API/API 3.1.x releases.
FWIW, CubicSDR upstream requires wxGTK 3.1 extensively. This package is stuck at an August 2018 source code date because backporting it to work with wxGTK 3.0 is no longer feasible.
I decided to go ahead and package up the 3.1.x release under the 'wxGTK' name. My thinking is that wxGTK will follow the development releases (ie, it would move to 3.2 once it is released, and then when a 3.3.x release is made, we'd fork off a wxGTK32 package, and wxGTK would move to 3.3.x). @tibbs, willing to review it?
This is now in place in Rawhide. To use wxWidgets 3.1.x, you should now BuildRequire wxGTK-devel. NOTE: for any packages that end up building against wxWidgets 3.1.x, I would request that you make me a comaintainer of your package so that I can do rebuilds in a side tag when there is a new release (all releases result in soname bumps for development releases).