Among other things, v3.5 added the capability to distinguish macOS-on-ARM from other platforms (issue 1528, PR 1530). However, since we only gained access to such systems late in the release cycle, the capability to run JME apps on them was omitted. In particular:
The LWJGL native libraries for “macos-arm64” weren’t included as dependencies. (commit de2e2d3)
No asset path was defined for a MacOSX_ARM64 version of “bulletjme”. (commit b40a91d)
Using JME 3.5.0-stable and some workarounds, I’ve run dozens of JME apps on a Mac Mini G5. I uncovered a few issues (one of which I’m still investigating).
With minor changes, JME 3.5’s support for macOS-on-ARM systems could be greatly enhanced.
I’m contemplating a v3.5.1 release for that purpose. The release could include unrelated low-risk/high-benefit bugfixes (such as PR 1762). However it shouldn’t include any breaking changes, such as those proposed at MacOS support overhaul, Apple M1 and breaking changes . (Breaking changes require a major release, and AFAIK none is planned.)
I believe a v3.5.1 release could be ready before 31 March, perhaps as soon as next week.
The bugfixes in lwjgl 3.3.1 aren’t really ones I understand (so they might affect us, but they are very “deep in the bowels” fixes). The improvements to macos support is interesting though given our current macos efforts:
* GLFW: An alternative macOS build now supports Cocoa calls on any thread.
* A different window toolkit (AWT, JavaFX, etc.) may now run at the same time as GLFW. It must be initialized before `glfwInit` is called.
* Enabled with `Configuration.GLFW_LIBRARY_NAME.set("glfw_async");`.
But all that is rationalising, its the openXR that’s the jewel in the crown as far as I’m concerned
@Ali_RS In my opinion, PR 1772 doesn’t belong in 3.5.1 because it’s not a bugfix. It would be safer to postpone it to a future release—one with a longer test phase.
@richtea As you’re probably aware, I’ve been testing “glfw_async” in JME’s “master” branch. I had hoped it would solve some of our existing macOS issues, but so far no success. Blindly upgrading LWJGL is a big risk. Unless it solves some major problem with 3.5.0, it doesn’t belong in JME 3.5.1.
It’s not too soon to start working on JME OpenXR: you can develop against JME’s “master” branch.
I propose to act as release manager for JME 3.5.1. This means: I would spend a day or 2 backporting the above changes into the v3.5 branch, running simple tests, publishing the release to GitHub and Maven Central, and posting announcements.
If we later discover that JME urgently needs LWJGL 3.3.1 or PR 1772, we could easily add them in a 3.5.2 release. So …
If anyone has objections or counter-proposals, please comment ASAP.
Unless I see such comments, I’ll begin acting as release manager in 48 hours.
It should appear in Maven Central Repository Search in an hour or two. Expect a blog announcement, a brief e-mail to donors, a README update, and a tweet during the next 24 hours.
Thanks to @Pavl_G, we now have proof that upgrading LWJGL to v3.3.1 will fix an important regression in JME 3.5: issue 1710. Therefore, we should backport the fix ASAP and publish a JME 3.5.2 release.