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.