To be honest, only like 10% of those are probably 3.2.2 worthy. And I already found one that needs to be reverted so it’s definitely important not to rush them.
The threshold for risk needs to be way lower than you’ve set.
For example:
970: RigidBodyControl doesn’t read/write velocities
…already this is a change in behavior if someone is counting on their velocities to be reset every time the object is saved/loaded.
Here is the question:
“Will these changes potentially break some existing user’s app?” If the answer to that question is “yes” in any way then it deserves way deeper discussion.
If I were to go through these one by one what would be the best way to mark the ones I think should definitely not be in 3.2.2? Remove the label and add a comment? Just add a comment?
I think it is ok, as no jme example directly calls to lwjgl. It’s the engine core using and calling this library.
The important thing to consider is the breaking changes of the new releases (which you can read them in release page) and see if they influence jme.
I have no idea about it but I think @tonihele and @javasabr can verify it as they are more familiar with.
There was the LWJGL 3 context fix that went along with it. I never experienced the problem on my projects. But it was painfully obvious when I used the JME tests launcher. I don’t know how that translates to a real use case outside the engine to be honest.
It is now more near the LWJGL 3 demo reference code. So I guess in that way too the fix is correct.
From @pspeed, but also from any knowledgeable person with opinions about what issues should or shouldn’t be addressed in v3.2.2 . Please comment. I’ll wait before moving on to the next step. All you need is a GitHub account. Or if you don’t have (and don’t wish to create) a GitHub account, post your comments here in the Forum.
I do appreciate the efforts to keep this discussion on topic, by the way.
I still plan to at least take a brief stab at kicking out a bunch of the ones that will probably change behavior. Anything that flat out didn’t work at all (threw NPEs, etc.) is probably safe because no one could have been using it before.
…but several other things are risky because code might be already working around the bug and will break. 3.2.2 should (as much as possible) not break anyone.
Ok. I’ve made my quick pass (one cola’s worth)… and removed the ones I thought were risky as far as existing apps possibly relying on the broken behavior. There were a lot more left than I’d originally guessed. List in github is down to 27 items now. I don’t remember what it was before.
Thanks for giving these issues your personal attention. I’ll study your changes to the milestones and any associated comments.
In general, I think the risks of fixing a bug have to be weighed against the risks of not fixing it. These risks depend on user behaviors that are difficult to predict. So these decisions often come down to a judgment call.
You seem to have a lot more relevant experience than I do, so I’ll probably rely on your judgment in most cases.
Yeah, it’s just that as much as possible second-point releases should cause no harm for users. And to me that includes the case where they’ve got 50 materials relying on current (incorrect) default behavior and if they upgrade to 3.2.2 it should look the same (for example).
Besides, we could start cutting 3.3 tomorrow if we wanted to… whose going to stop us? So anything anyone feels critical about is already there for the using, really. Which definitely means 3.2.2 should be a stable upgrade path over anything else.
I’ve barely looked at MonkAnim . Based what little I learned while studying issue 972, I suspect MonkAnim is incomplete and not release-ready. But I don’t know.
To release version 3.3.0, we’d also need a motivated release manager.
Re transitioning to 3.3 to get fixes, I can only speak for myself. I have a large investment in the old animation system, so I’m reluctant to switch to 3.3, where all the animation classes I know are deprecated.
I think we should release 3.3.0 alpha 1 (or pre-alpha) ASAP.
These days more people are getting interested in new animation system and gltf, you can see from the posts are made in forum.
If we release 3.3 alpha 1 or pre-alpha then all whom are interested will have a chance to test it and report issues, then finally someone might come and fix them.
Unfortunately @nehon seems to be inactive these days but I really really really hope he get back and continue his awesome work on JME.
I know we can always build from master just like what I have been always doing but there are some people who might have trouble with gradle or building from source …