Engine Versions 3.3.x

Just noting here just in case anyone is writing a list of changes. I didn’t submit a PR because they’re so basic there’s no need for discussion.

  • Added chaining methods for ColorRGBA that returns itself.

    • setRed
    • setGreen
    • setBlue
    • setAlpha
  • Added a static method to create ColorRGBA objects from RGBA255 values.

    • ColorRGBA.fromRGBA255(int red, int green, int blue, int alpha);

But the commits you refer to are only in the master branch of the repo, so they won’t affect JME version 3.3.1, which is the topic here.

And they are new features and so wouldn’t be a candidate for 3.3.1.

Sorry. I don’t know what I’m doing today.

3 Likes

And still we love and respect you.

6 Likes

PR 1358 is now integrated into the master branch and cherrypicked into the v3.3 branch. So we have a new release candidate: 4b62b70

2 Likes

I decided to include a fix for issue 1360. The latest release candidate is 618e890.

Unless there’s a serious issue with 618e890, I plan to release 3.3.1 about 24 hours from now.

1 Like

Hm. I pushed a tag for “v3.3.1-stable”. I expected GitHub to build the release automatically, but I don’t see any evidence of that happening.

Any advice?

I do not know what the problem is, but I noticed two days ago that it does not look like there are snapshots in jitpack anymore. My projects that use the snapshots will no longer build, and I do not see them listed in jitpack.

EDIT: I should clarify, there are no more 3.3.x snapshots.
EDIT 2: Actually, I think I found it, but it is missing the version number now…?
https://jitpack.io/#jMonkeyEngine/jmonkeyengine/-SNAPSHOT

I wonder if it’s because the “v3.3” branch isn’t listed in .github/workflows/main.yml
But in that case, how did the v3.3.0-stable release happen? @pspeed ?

I pushed the tag and magic happened. I don’t understand the magic… I just invoke it.

…when it doesn’t work, I don’t really know why.

1 Like

Thanks, Paul. It’s good to know the “magic” worked for you as recently as 30 March.

Before I delete the tag and experiment, I’d like to hear from @riccardoBlb , since he did most of the work to set up GitHub Actions.

Not according to travis.
https://travis-ci.org/github/jMonkeyEngine?page=1&tab=repositories&timeInterval=month

The Engine hasn’t used Travis since October. That’s when Riccardo moved it over to GitHub Actions.

I see, do they have something like the link to examine builds?

Here’s the link: Actions · jMonkeyEngine/jmonkeyengine · GitHub

Thanks, that looks way more useful than travis.

I’ve reconfigured the workflow and deleted the tag. I’ll retry with a new tag.

Edit: that didn’t work either. GitHub ran the workflow for the commit, then ignored the pushed tag.

I’m brainstorming:

  1. Because GitHub remembers that I recently pushed a tag with the same name?
  2. Because the pushed tag arrived too long after the commit?
  3. Some other reason??

It doesn’t automatically build all tags as releases. To create a new release you need to use the github ui.

(it can use an existing tag, or create a new one)

1 Like

@RiccardoBlb: Hm. Usually I wait to “draft” the release at GitHub until after all the the JARs and other Maven artifacts have been deployed to BinTray/JCenter. Each time I pushed a tag to GitHub, I expected the DeployRelease job to run, but it didn’t.

When should I expect the DeployRelease job to run?

1 Like