Next release(s) of the Engine

I’m curious what will be in the next release of the Engine (not the SDK). If there’s a roadmap, I haven’t seen it.

Are there enough bugfixes to justify a 3.2.2 release, and if so, what should be in it (other than null integer mat-param overrides)?

Assuming there will be eventually a 3.3 release, what exciting new features will it include? Any guesses how close we are to 3.3.0-alpha1?


In 3.2.1 stable, the PBR shader doesn’t compile due to a typo. It’s been fixed on master, but it sounds like 3.2.2 material to me.


Well I have a road map, but I have trouble finding time and motivation to work on it… happened before, I’ll get back to work eventually.

There has been some bug fixes and they deserve a 3.2.2 yes

Then 3.3 alpha needs to be tagged and delivered
Here is the change log

Many of these points needs a bit of work, especially in pass shadows that are not still merged.


Thanks for the change log and the status update, Rémy. I hope your time and motivation return soon.

Personally, I’m more excited about 3.2.2 than 3.3, though I realize they’re both important.

Is there anything I (or others on this forum) might do to assist you?

1 Like

I’ve set myself a goal of releasing v3.2.2 of the Engine before January 1st.

As a Contributor (though not a Core Developer) I can do most of the work myself. However, I’ve never managed a JME release before. And since I suck at Git and am unfamiliar with large chunks of the code, I’ll doubtless need help. Therefore:

  1. I’m asking for help.
  2. Since I don’t know exactly what help I need, I’ll try to make the process transparent, so people who are willing and able to help can jump in at appropriate times.

A few assumptions and ground rules:

  1. Release discussions should take place in the Forum or on GitHub, not in the (private) chat room.
  2. I’m not concerned with releasing new versions of the IDE or the SDK or the Wiki, just the libraries.
  3. 3.2.2 is for low-risk bug fixes and Javadoc fixes only–no new features, and no fixes that impact large portions of the code.
  4. 3.2.2 will be built from the v3.2 branch of the repository at GitHub - jMonkeyEngine/jmonkeyengine: A complete 3D game development suite written purely in Java. .
  5. In general, changes destined for 3.2.2 must first be committed to the master branch of the repo.

The plan of action:

  1. Post this comment/announcement at the Forum.
  2. Review all open pull requests, open issues, and recently-closed issues on GitHub. Decide which ones to target in 3.2.2 and tag them appropriately.
  3. Issues opened after this point will generally not be considered for 3.2.2 .
  4. Review all commits to master since the v3.2 branch was created. Decide which ones to include in 3.2.2 and publish the list to the Forum for comment.
  5. Commits after this point will generally not be considered for 3.2.2 .
  6. Cherry-pick commits from master to v3.2.
  7. Build 3.2.2-alpha1 and commence alpha testing. (forum announcement)
  8. Build 3.2.2-beta1 and commence beta testing. (forum announcement)
  9. Build 3.2.2-stable release.
  10. Some privileged person (not I) clicks on a button to publish the release and make it official.

Note that I’ll be mostly unavailable from 23 December through 27 December.

Questions? Comments?


Release discussions should take place in the Forum or on GitHub, not in the (private) chat room.

Great, it will make people know more about how it look like.

And since I suck at Git and am unfamiliar with large chunks of the code, I’ll doubtless need help.

i also dont know how this look in JME exactly. In previous work we had:

  • creating issue branches from current master. Fix and commit or add feature.
  • autotest (repo plugin) run and test if all still work.
  • Create release branch with next number (globalversion.featureversion.bugfixversion)
  • merge required features or bug fixes to release
  • test fully release branch.
  • merge into master and TAG newest commit with release number.
  • if older tickets for next releases are backward in commits from current master, then update and test again.
  • repeat

here i see also:
Build 3.2.2-alpha1 and commence alpha testing. (forum announcement)
Build 3.2.2-beta1 and commence beta testing. (forum announcement)
Build 3.2.2-stable release.

Not sure if all issue branches are made from 3.2 branch, if not then need update them first.

since now i understand:

Review all commits to master since the v3.2 branch was created. Decide which ones to include in 3.2.2 and publish the list the Forum for comment.

this is the main problem? because it was commited into master directly without ANY workflow? so this will require to create 3.2.2 version that will use 3.2 base + decided commits from current master, but not sure what about master branch, because it should contain only stable release commits.

1 Like

In a volunteer project with few volunteers, that process would ensure that nothing would ever get done.

It’s a “cover your ass” process for large projects with paid workers who are not really skilled enough to be doing the work properly. (ie: most professional software teams that are a mix of skills) Edit: also it’s totally unnecessary when there are pull requests already forcing the branch+patch+approve methodology.

Here, we develop new stuff against master. We often put fixes against master. Current master is what will someday be 3.3.

Some fixes to master may also be relevant to 3.2 and so will be cherry-picked. This is literally just one command, so simple. “git cherry-pick commitId” That’s it. Test. Done.

The problem is that the type of fixes that should be back-ported to 3.2 are extremely rare. In general, it should not be “everything that fits” but instead “things that fit and are required”. For example, javadoc fixes are harmless but I wouldn’t consider them a candidate for a new 3.2.x release unless we were already doing other things. But something like “X is causing bullet to crash and this will fix it without causing compatibility problems” is a fine reason to have a 3.2 release.

The reason this comes up at all otherwise is because 3.3 is on no one’s horizon at the moment… so now we try to see how much we can sneak into 3.2 instead of just staring a 3.3 release. (I don’t know what’s holding up a 3.3 release as I haven’t been keeping track.)



but what about “things that NOT fit or are NOT required”, this things will stay in “their branches” and removed from master (via rebase?)

so master will rebase to 3.2 and only “things that fit and are required” will be merged again into it to create 3.2.2?

so other current master commits will just stay in “their branches” but removed from current master right?

What branches are you talking about?

There is master where all changes are COMMITTED and all PRs are COMMITTED.

Then there is the 3.2.x branch which was the thing we released 3.2 from.

ok so i understand master stay as it is, just 3.2.2 release branch will be created from master TAG 3.2(or commit from 3.2 whatever) and some of commits merged into it. so master will stay as it is.
later current master will be 3.3, so next will be 3.3.1 with taken some of master commits again and again 3.4 from new current master.

dont get me wrong, i try understand workflow that is there :slight_smile: if i understand it correctly, nothing more to add.

Releases are tags.

Right now there are only two branches we care about. 3.2.x and master.

3.2.? releases are tags on the 3.2.x branch.

There are no useful release tags on the master branch.

WHEN we decide we are ready to start working towards 3.3 then we will make a 3.3.x branch from master. A 3.3.0-alpha release tag will be a tag on the 3.3.x branch.

New development will continue on master (for some future 3.4 branch). 3.3 bug fixes, etc. will be done to both master and 3.3… whether it’s committed to 3.3 and cherry-picked to master or commmitted to master and cherry-picked to 3.3 just depends on who is paying attention when.

But for the moment, there is only master and 3.2. This thread is about which commits (commits) to cherry-pick from master to the 3.2.x branch. The commits already happened.


now i understand it fully, thank you much :slight_smile:

1 Like

Without having read all that, we’ve only had alpha and beta testing for a new major version (e.g. 3.3) so far, I guess the reason is that (usually) bugfixes don’t require extensive testing and the folks who would do the testing are already using master since a few months (at least that’s what I hear most of the time on our Discord: “I consider master to be stable enough”).

So I don’t know if it’s necessary to push these bugfixes through an alpha and a beta phase, especially given the time constraint (it’s like two weeks to go, that means less than a week to test for each tag. [On the other hand, if there are no objections to alpha, we don’t need a beta]).

But at the end of the day I’m happy that someone takes care of pushing jME forward, so this is just what came to my mind, technically it doesn’t matter much


Yep, that’s true. If sgold is feeling uncomfortable going straight to stable then a beta is probably a good idea. Just to make sure everything works ok before calling it ‘good’ or whatever.

…but I also see no strong reason for a 3.2.2 alpha.

1 Like

Thanks for the input on testing phases.

I wasn’t envisioning much alpha testing. Maybe 24 hours to run through jme3-examples with various options. It’ll also be a chance to make sure the release process is working smoothly: all the JARs generated and uploaded to the right places, etcetera.

I’m open to the idea of skipping alpha entirely. Let’s see how things go in the coming week.

1 Like

Yeah, to me working out build-related issues and such could be done with a beta.

1 Like

Shout out to all the people working on jMonkeyEngine! Your work is very much appreciated, it’s totally awesome!


I’ve completed a first pass over the PRs and issues, tagging them with a new v3.2.2 milestone if I hope to include fixes in the new release. There are still a couple issues I’m unsure about and a couple that haven’t been fixed in master branch yet.

Here’s a snapshot of issues currently tagged for inclusion:

240: TestBlenderObjectAnim fails with an NPE
358: Centered BitmapText is rendered blurry
371: Sometimes after deserializing a J3O, animations are broken
617: FlyByCamera inconsistencies (bugs when using setUp(z-axis))
632: Make tests more android friendly
740: TestRagdollCharacter crashes
742: attachment nodes are not compatible with ignoreTransform geometries
816: BoneTrack.setKeyframes() throws NPE with assertions enabled
825: SpatialTrack.clone() sets the trackSpatial to null
829: BoneTrack.clone() adds scales
843: MaterialDebugAppState is not reloading the changed shader instead reloads the old one
848: BlendEquations and BlendFactors gets not updated correctly
861: please add *-javadoc.jar files to JCentral deployment
867: Bullet skipping enqueued tasks
877: physics joints don't work unless both bodies are dynamic
880: J3MLoader silently treats "true" as false when parsing booleans
883: extra physicsTick() callbacks with ThreadingType.PARALLEL
886: TestPhysicsRayCast uses a ray that's too short
887: with Native Bullet, debug mesh ignores scaling of CollisionShape
889: disabled physics control gets added to a physics space
894: SliderJoint.setRestitutionOrthoLin() sets wrong joint parameter
897: Native Bullet breaks TestBetterCharacter
898: Native Bullet breaks TestFancyCar
908: jme3test.bullet.TestQ3 crashes due to missing assets
911: PhysicsRigidBody sleeping threshold setters have unexpected side effects
913: No native implementation for PhysicsJoint.finalizeNative
915: CI build process doesn't update
916: PhysicsSpace doesn't use SafeArrayList for its collisionListeners
917: fails to set native object's angular-only flag
918: Point2PointJoint.getImpulseClamp() returns the damping value instead
919: native implementation of TranslationalLimitMotor.getLimitSoftness() has wrong name
923: HingeJoint.enableMotor() not working
928: 64 attached or detached BulletAppStates with parallel threading causes JVM to crash
931: RagdollUtils can miss model meshes or use wrong ones
954: Node returns null bounding volume.
957: Triangle setters should null out the cached center and normal
961: Engine doesn't build on openjdk-11
970: RigidBodyControl doesn't read/write velocities

For the latest information, go to GitHub, of course:
Issues · jMonkeyEngine/jmonkeyengine · GitHub

One of the issues I want input on is 871: “Update LWJGL to 3.1.6” Does it fix any known issues? How risky is the change?

there anyway is:

said SOME tests passed

so need test it more it seems.

1 Like