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?
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:
A few assumptions and ground rules:
v3.2 branch of the repository at GitHub - jMonkeyEngine/jmonkeyengine: A complete 3D game development suite written purely in Java. .master branch of the repo.The plan of action:
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.master to v3.2.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:
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.
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.)
thanks.
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 
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
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.
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.
Yeah, to me working out build-related issues and such could be done with a beta.
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 libbulletjme.so
916: PhysicsSpace doesn't use SafeArrayList for its collisionListeners
917: HingeJoint.read() 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:
https://github.com/jMonkeyEngine/jmonkeyengine/pull/974
said SOME tests passed
so need test it more it seems.