Oops! I just discovered one more “interesting” commit, which I had incorrectly categorized as comments only:
Properly cleanup the DetailedProfilerState when it's detached · jMonkeyEngine/jmonkeyengine@9dadc29 · GitHub
Properly cleanup the DetailedProfilerState when it’s detached
Obviously I’m ok with the J3MLoader change as:
a) I did it, and
b) it’s only an exception message change and hugely useful.
(I’d forgotten about that commit message and it almost made me snort pepsi up my nose.)
This:
https://github.com/jMonkeyEngine/jmonkeyengine/commit/302e746a944f8f536fbb33fb059805e44d72c987
…is probably also ok. I think it’s not a functional change just an optimization. Likely less error prone now than it was.
The light probes one:
https://github.com/jMonkeyEngine/jmonkeyengine/commit/db48b98a2eeb3ca87446e56c2472d993a662d9c9
…could be a change in behavior for someone. Probably best skipped.
This one should be fine:
https://github.com/jMonkeyEngine/jmonkeyengine/commit/0fb5eeddd7e917a5684a3980af26d911403f8be8
…it just prevents an NPE.
This one:
https://github.com/jMonkeyEngine/jmonkeyengine/commit/319656a0561ed18c29760eae82fdc31fb03ba790
…is harmless… but also silly. The logger already knows what class it’s for and there is no reason to include the name of the class in the log message. (This idiom still makes me laugh after all these years.)
This one:
https://github.com/jMonkeyEngine/jmonkeyengine/commit/9dadc2998696858f2f58b0a193a553e3e4b47c2f
…should also be safe. The incorrect behavior it changes was at best a no-op before and at worst an error. I can’t see how an app could have been relying on the keys to still enable the removed app state.
Thanks, Paul.
If anyone else wants a crack at this list prior to Beta, please let me know.
The cherries have been picked, all 70 of them. Continuous integration is running as I type this.
I believe I have 1 or 2 more things to do before building 3.2.2-beta1.
@sgold You chose not to cherry pick the following 3 commits from master to 3.2.2.
commit 40f6a7cc7ab56ede30f94a0a80299181975ce867
Date: Fri Aug 31 10:43:39 2018 -0700
avoid JDK10 so Travis CI can succeed
Cherry-pick? NO - already integrated into v3.2 branch
commit 7da493d1b151030a9c928581c2e8d0bb61bddc3f
Date: Thu Nov 29 14:32:18 2018 -0800
AppVeyor: invalidate cached ZIP file if gradle.properties has changed
Cherry-pick? NO - already integrated into v3.2 branch
commit 938c28fd2bf946c80c0be0185a30b7fde3ded8b1
Date: Sun Dec 2 10:06:59 2018 -0800
trigger AppVeyor build for additional changes
Cherry-pick? NO - already integrated into v3.2 branch
What do you mean by “Already integrated into v3.2 branch” - I was under the assumption that I’d see the commits on 3.2 branch, but I don’t see them.
Also, what does the following commits do? I’ve seen them being committed quite often.
[ci skip] bullet: update osx natives
[ci skip] bullet: update windows natives
Those 3 commits affected only the YML files used by continuous integration (CI). During CI testing last night, I made those edits in the v3.2 branch — at 0090e3e2798f975f3b8a14d21372dce8d55682ff.
Those are commits of the native Bullet libraries. The commits are performed automatically by the continous-integration servers at AppVeyor and Travis. The [ci skip] prefix tells the CI servers not to test these commits.
Hm. I pushed the tag, and CI passed, but Travis didn’t recognize it as a tagged commit.
I’ve had this problem with Travis on other projects. I believe it happens because too much time elapsed between pushing the tag and pushing the commit. I’ll try again in 8 hours or so — after I get some sleep.
I tried again, using Git Gui, but still no deployment by Travis:
Travis CI - Test and Deploy Your Code with Confidence
Skipping a deployment with the releases provider because this is not a tagged commit
I’m unsure what to do next. Help!
Looks like a tag to me, maybe travis only reacts to tags on master?
I mean that message is related to travis and then the Environment Variable $TRAVIS_TAG is not set. Really strange…
This looks relavent: git - Travis-CI skipping deployment although Commit is tagged - Stack Overflow
This could definitely be it. It’s strange because it used to work before though.
It’s also a bit of a bad situation but on the other hand since we have no github-pages branches or something we can safely build every branch, it’s actually even more future proof since we don’t need to change v3.2 to v3.3 etc
You didn’t cherry pick those commits since it was easier to make a new commit to 3.2 branch right?
No. I didn’t cherry pick them because they were redundant. The changes were already in the branch.
Sorry folks, I’ve been off-line most of today, and now I’ll be off-line until Thursday. I might have time for one more try tonight, but that’s it for the next 4 days.
If one of the core devs would build 3.2.2-beta1 in my absence, I’d be most grateful.
It looks like that worked. There’s a new release up at GitHub:
Release jMonkeyEngine 3.2.2-beta1 · jMonkeyEngine/jmonkeyengine · GitHub
Now we just need one of the core devs to upload it to JFrog.
Thank you sgold for making it happen!
They are automatically uploaded to bintray… just need to have the “Publish” button pushed. I’ve done that.
Maybe because the tag isn’t on the master branch but the v3.2 branch and it doesn’t make sense to count this between branches [as v3.2 WILL intentionally be behind master]?
In English, “since” means stuff that happens after some event. Since this was just now released, no commits have happened after it yet. So no commits after this release, ie: no commits since this release.
