Next release(s) of the Engine

Development
160

Perhaps there should be a 3.2.4 release of the JME libraries.

Motivation might come from the following issues that impact v3.2.3:

I’m thinking sometime in early July. I’m willing to manage said release.

5 Likes
161

i see milestone was set for 3.3. also see its already in 3.3,
so i understand its just moving this commits into 3.2 to let 3.2 also have them.

BTW:
in JME github page README there is:

jMonkeyEngine is a 3D game engine for adventurous Java developers. It’s open-source, cross-platform, and cutting-edge. 3.2.2 is the latest stable version of the jMonkeyEngine 3 SDK, a complete game development suite. We’ll release 3.2.x updates until the major 3.3 release arrives.

i think it would require some changes.

162

its just moving this commits into 3.2 to let 3.2 also have them

It’s much more than that. In some cases the fixes aren’t yet committed to master branch.

If we decide to proceed, my first move would be create a “3.2.4” milestone at GitHub and re-target some issues to it.

i think it would require some changes

Changing the README is easy. The hard part is deciding what it should say.

After I released v3.2.3 of the Engine, I held off updating the README because there was no 3.2.3 SDK yet. There’s still no 3.2.3 SDK. As a long-time SDK user, I’m sad about that.

163

The engine does not wait for the SDK as I understand things, just sayin…

Probably a waste of time to release a new version of SDK imo. Theres many things that oracle rendered useless and they cant be fixed until jdk 13.

164

I have to disagree a little bit here, nothing will be fixed by jdk13, but reflection will stop working entirely, no more warnings. We will have to move to modules and cut jdk 8 support.

165

To avoid further derailing this release thread, replied here:

1 Like
166

What’s needed for an updated SDK? Just rebuild with updated references to the current stable engine source?

167

in Properties, everything under the Application category has to be redone as far as I know.

I know the desktop category cant be fixed untill jdk 13. Thats all cross platform deployment stuff.

Also, gradle was made part of netbeans and that wont be fixed until 13, from what I read. Thats something @Darkchaos was waiting for so he could implement jme gradle projects.

I think there may be more but I have not personally needed other things so am not sure.

168

Let me rephrase that: what would be needed for an SDK build that works with/uses 3.2.3, without reference to using a newer version of Netbeans/support for other stuff happening in the Java world?

I think that is more to the immediate point as far as @sgold’s concern goes.

169

A new way to download the jdks. Ever since the jdk downloads on oracle’s page changed (and became non free to use), travis can’t build the sdk.

170

I’m sure it’s not this simple and this will be a stupid question, but why can’t it use this?

171

I think @Darkchaos tried with adoptopenjdk, but I’m not sure whether it worked or not. Maybe he can tell you more.

172

I didn’t have the time yet for adoptOpenJDK and I am still uncertain whether we should bundle a jdk with the SDK. The script would also break again for java 11, so the question is whether we should work towards nb 11 (whatever is recent) and the relevant jdk already. But that would mean no v3.3.2 support, which is intolerable as well.

1 Like
173

I’m still sad about the lack of new SDK releases. The Engine and SDK remain intertwined. Much of our documentation is still SDK-oriented, and people still confuse the Engine with the SDK. But as @mitm noted, the Engine does not wait for the SDK…nor should it.

Today I created a v3.2.4 milestone (with a 4 July due date) and started targeting issues and PRs to it:
v3.2.4 Milestone · GitHub
I welcome constructive feedback on what should/shouldn’t be included in this milestone.

Soon I’ll be making a list of commits to cherry-pick into the v3.2 branch. I received scant feedback on the v3.2.3 list, so the review period for the v3.2.4 list will be much shorter.

2 Likes
174

In case anyone is unaware, there’s now a v3.2.3 SDK. Thank you, @Darkchaos!

v3.2.4 of the Engine is still a work in progress. So many commits I want to include—more than I expected. You can follow my progress at Google Docs:

I imagine most JME folks think in terms of issues and pull requests, not commits. I’ll publish lists of issues and PRs before I commit anything to the v3.2 branch.

6 Likes
175

Here’s the current list of issues to be addressed in v3.2.4:

For the most up-to-date list, follow this link: Issues · jMonkeyEngine/jmonkeyengine · GitHub

9 Likes
176

I hope to start cherry-picking on Wednesday. Please get any feedback to me by 1600 hours GMT on Wednesday 10 July.

Here’s the current list of PRs to be incorporated into v3.2.4:

For the most up-to-date list, follow this link: Pull requests · jMonkeyEngine/jmonkeyengine · GitHub

6 Likes
177

Here’s a list of commits (to be cherry-picked into v3.2.4) that don’t seem to be associated with an issue or PR:

  • 2ab0319 jme3-examples: apply the “dirt_normal.png” normal map where appropriate
  • fca8bcf make native Bullet the default for jme3-examples (instead of JBullet)
  • fff16c2 TestIssue99: specify panel widths, clarify interpretation of results
  • 74588d9 adapt the caption of the string
  • ba340cf add a test case for issue #99 (blendMode=“multiply” in NiftyGUI)
  • f60ff58 Add bullet extraction directory, bin and vscode config to gitignore
  • 2124e3e TestGltfLoading: comment

I hope to start cherry-picking on Wednesday. Please get any feedback to me by 1600 hours GMT on Wednesday 10 July.

8 Likes
178

Note that this fix may break any code that has already worked around the issue in some other way.

1 Like
179

You know this code better than me. How likely is such breakage? What are the most likely workarounds?