I’m off work on Monday and I’m hoping to spend some time going through the commits since 3.3 beta1 to see what needs to go into beta2. I’d really like beta2 to be the last 3.3 release before just renaming it stable and pushing a stable release.
Consequently, I want to make sure that I don’t miss some critical commit as I’m going through them. My criteria for choosing may be different than yours but that doesn’t mean I can’t be talked into something.
If you have a commit that you know needs to go into beta2 then please let me know.
Base criteria for 3.3 beta2 cherry-picking:
the commit does not add a new feature, 3.3 is feature-frozen
the commit does not break or alter existing API behavior (other than fixing a bug)
The second one is where there is sometimes a narrow gray area worth discussing.
We have about 48 hours before I’m going to think about tagging the branch. Hopefully that’s enough time to weigh in.
I feel this is a issue that should get resolved before a 3.3-stable. https://github.com/jMonkeyEngine/jmonkeyengine/issues/1191
Causes the context to not be resizable. Thus resolution cannot be changed after launch, and resizing the window has no effect on the context. No PR currently available.
I know it has been broken a long time, but it would be really nice to get this fixed as it is a basic function.
If it’s not fixed then it I can’t cherry-pick it in. And I’m not fixing things just releasing what’s there.
So the choice is release what’s there or wait until someone fixes this… ie: wait indefinitely. Which I’m also fine with because that’s 0 work for me.
Either way, if someone wants this fixed then they’ll need to fix it. It doesn’t affect me personally so it’s not likely an itch that will bubble up in my personal priority… though I do think it’s important.
Yeah, to be clear I’m not fixing anything new… just looking at what I should cherry-pick from master into the 3.3 branch. The commit has to exist first before I can do that.
I will add the commit you mention to my list, though.