Jme 3.7

Development Engine Development
1

I believe it’s time to begin working toward a v3.7 release of JMonkeyEngine.
Is anyone interested in acting as our release manager for JMonkeyEngine 3.7.0?

The release manager is responsible for driving the release process. This includes:

  • deciding the scope of the release: which features/fixes to include,
  • setting the schedule,
  • organizing any required testing,
  • tracking issues and pull requests,
  • generating alpha/beta/production releases,
  • writing up the release notes, and
  • publicizing the final product.

While acting as release manager requires some technical skills (such as Java, Gradle, Git, GitHub, and Nexus), communication/people skills are just as important. If you need guidance or advice, there at least 3 former release managers (@Ali_RS, @pspeed, and myself) active here at the Forum.

Any volunteers?

11 Likes
2

I’m ready to try :slight_smile: I’ll need tight guidance since I’m not an expert in any of the tech skills you mentioned.

10 Likes
3

Thanks for volunteering, @adi.barda . This is an exciting time!

Unless someone else steps forward or objects, you’ll manage the release.

I have plenty of questions:

  • What sorts of guidance will you need? Are you expecting any other help from the JME community? I realize you can’t anticipate everything you might need, but some examples might ease my mind.
  • What’s your vision? For v3.7.0, what changes (including bugfixes and features) would you like to make to the Engine, relative to the current “master” branch? I’m particularly curious about how the framegraph framework might fit into you plans.
  • Do you also have plans for the SDK and/or the Wiki?
  • When would you like to begin managing the release?
  • When would you like feature freeze to occur?
2 Likes
4

Thanks! my motivation is to contribute some of my time to the JME effort.
First, I work in a cyber security company (Checkpoint) where our product has no releases. We have a continues delivery process where features are streamed into production as soon as they are ready and pass all tests so first thing I would like to know more about the process of creating a release.
How do I observe all the candidate features / fixes to include? are there a list of PRs which I can observe to choose from?
In general, I want to include as many as possible ready to ship features / fixes which passes our tests. I especially want to includes @JhonKkk recent upgrade to the engine.
I guess that “heavy” (lots of code & lots of value) PRs gets priority, test them first and then move on to the next PRs see that they don’t break each other.
I would like to know What is the best practice for testing a candidate branch? first merging all the PRs then testing or merge each PR, test the branch then merge the other one, test and so on.
How do we track issues / features?
How to publish an official engine version?
I only have a Windows machine available so what needs to be done if Linux / Mac is needed for the testing process?
Regarding a new framegraph API - I read what JhonKkk wrote in his post about framegraph in the future of JME and TBH didn’t understand much. I need to understand if such important core features can be added side by side with the current architecture and be activated with some kind of a feature toggle.
I prefer that public API will not have breaking changes as much as possible.
I never used the SDk (mybe I should start?). I thought it has an independent release cycle. When a new engine version comes out does it mean an SDK version comes out too?

Last thing - my country, Israel is currently at a state of war and this affects our everyday life which means that from time to time my availability will be limited.

3 Likes
5

I can help with testing and potentially PR reviewing.

On things for 3.7; back in JME 3.4 dropping jme3-vr was discussed. At the time I was strongly against but I’ve come around to that position. Any new virual reality projects ought to use OpenXR one way or another and jme3-vr is OpenVR or worse. How do we feel about deprecating everything in that module in preparation for removal in a future release?

At the time it was suggested that VR would be better supported as a seperate library and having written one I obviously now agree

4 Likes
6

Don’t worry about the SDK. We got it. We’ll follow up with a release shortly after jME new version is out.

I’m not sure if this is really ready at the moment. But no one is to say that 3.7 can’t be followed by a 3.8 or whatever in a very short succession. Doesn’t need to be a year, not even a month, right?

2 Likes
7

There are, plus there are lists of “issues” (which include feature requests), plus of course you can open new issues if you become aware of some need.

One of the first things we’ll need to do is add your GitHub account as a member of the jMonkeyEngine project (at GitHub) so you can manage its issues and pull requests. What’s your GitHub username?

I especially want to includes @JhonKkk recent upgrade to the engine.

Last I heard, JhonKkk was refactoring and the upgrade was a work in progress. It’s hard to predict when it will be ready for integration.

What is the best practice for testing a candidate branch? first merging all the PRs then testing or merge each PR, test the branch then merge the other one, test and so on.

Each PR should be tested before it is integrated to the master branch. At intervals, the release manager generates test releases (such as 3.7.0-alpha1 or 3.7.0-beta2) for broader testing by the community.

How do we track issues / features?

Using the GitHub website.

How to publish an official engine version?

There are instructions in the Wiki: Engine Release Guide :: jMonkeyEngine Docs

I only have a Windows machine available so what needs to be done if Linux / Mac is needed for the testing process?

You’ll need to rely on others, I suppose. Many community members use Linux. I have remote access to a Mac.

Last thing - my country, Israel is currently at a state of war and this affects our everyday life which means that from time to time my availability will be limited.

That’s understood. Try to keep us informed of any impact on the release.

1 Like
8

So if I understand correctly we should have a process something like the following:

  1. Decide on release scope - Select PRs to integrate
  2. Set a release date
  3. feature freeze
  4. Fork an alpha-1 release branch from master
  5. Integrate PRs to the alpha-1 branch
  6. Perform Tests on alpha-1 branch
  7. Observe the testing results
  8. Create next release branch (alpha-2) from master
  9. Integrate PRs which proved to be stable enough from the prev. iteration
  10. Tests
  11. repeat 7-11 until we have a release candidate branch
  12. code freeze
  13. release
  14. release notes + documentation
  15. hot-fix if needed

==================================================================
How much can I rely on the current automation tests?
Do we test plug-ins integration as well or just the core?
In general, do we want to strip features from the engine and transform them to plug-ins with independent release cycles? Like particle system, VR etc.

1 Like
9

scenemax3d

1 Like
10

I have a m1 max MacBook, can test anything we need on mac

1 Like
11

I’m for removing any open-vr support so people don’t accidentally start a project based on it, they should really only be using openxr now.

3 Likes
12

Good luck @adi.barda, let us know how is going.

Are you guys willing to merge the PRs for the animation system JavaDoc? I was working full-time on them, and will be pleased if someone honors this work maybe by merging them after a final review.

2 Likes
13

A few comments on the release process:

  • Testing sometimes takes longer than expected. I recommend being vague about the release date until you see how testing progresses.
  • Pull requests are always integrated to the “master” branch. That’s so their commits will automatically be included in all future release branches (“v3.8”, “v3.9”, and so forth). Once you create the “v3.7” branch, you’ll be responsible for deciding which “master” commits belong in v3.7 and which don’t. For each commit that belongs in v3.7, you’ll use the “git cherry-pick” command to apply it to the “v3.7” branch.
  • While it’s customary to create a Git branch for each feature release (“v3.5”, “v3.6” …) we don’t create branches for patch releases (“v3.3.2”, “v3.6.1”) nor for pre-release builds (“3.3.1-alpha1”). Releases and pre-release builds are marked with Git tags. Tags are distinct from branches. Prior to creation of the “v3.7” release branch, you can create builds directly on “master” branch. Once you’ve created the release branch, builds related to v3.7 should be created only on the release branch. Does that make sense?
  • To the extent possible, I recommend documenting things as you go along and not waiting until the very end. In particular, if you write detailed release notes for each pre-release build, it’ll simplify writing up the feature release.

How much can I rely on the current automation tests?

The automated tests have low coverage and rarely expose issues other than build failures. Running the jme3-examples apps by hand is tedious and time-consuming, but important. Once pre-release builds are available, the community should experiment with them, and that usually exposes some surprises.

In my opinion, the key to ensuring a quality release is focused testing on each major change since v3.6. (That’s another reason to publish detailed release notes for the v3.7.0-alpha1 build—so you know what all has changed in the past year!)

Do we test plug-ins integration as well or just the core?

The Engine release manager isn’t responsible for 3rd-party software such as Lemur and Minie. You will be responsible for all modules that are officially included the Engine. That means:

  • jme3-android,
  • jme3-android-native,
  • jme3-android-examples,
  • jme3-awt-dialogs,
  • jme3-core,
  • jme3-desktop,
  • jme3-effects,
  • jme3-examples,
  • jme3-ios,
  • jme3-jbullet,
  • jme3-jogg,
  • jme3-lwjgl,
  • jme3-lwjgl3,
  • jme3-networking,
  • jme3-niftygui,
  • jme3-plugins,
  • jme3-plugins-json-gson (new for v3.7!)
  • jme3-plugins-json (new for v3.7!)
  • jme3-terrain,
  • jme3-testdata, and
  • jme3-vr (if you decide to keep it going).
2 Likes
14

I find it a little confusing.
As I see it:
each PR (feature branch) == new feature / fix (may have many commits)
master branch holds latest stable version
we fork v3.7 branch from master
merge to v3.7 branch all candidate PRs (feature branches)
perform tests on v3.7 branch
when it’s ready - we merge it (v3.7) back to master
a flow like demonstrated in this diagram:

image
image1600×894 31.1 KB

I think it’s simpler than cherry-picking commits from master… or am I missing something?
I’m not familiar with the process you described. is it mandatory? I’m not comfortable with merging features to master before they where even tested. can cherry-pick append to the release branch all PR’s commits at once?

2 Likes
15

Your contribution is highly appreciated.

2 Likes
16

I was also confused by this. Surely as a major release anything in master already is in for 3.7 (and if not it shouldnt have been in master).

Edit; unless now that i reread it, is the cherry picking only for rare features which miss the general branching for 3.7 but still want to be added late to the bus?

2 Likes
17

The jMonkeyEngine release process is very simple (and I use it in my own projects). Every PR is tested on its branch before being merged into master. By doing so, you are mostly on the safe side, unless something unexpected happens, which would mark the causative PR as regressive and a rollback or a fix will be mandated then. Some projects use a release branch, though I think it’s redundant, as the release can be created by creating a new tag and release while on the master branch. Double testing using a release branch is a very good strategy in critical-safety systems, but I think it will consume a lot of time in this case without offering much further than just testing feature/fix branches before merging (this even removes some burden from the release manager by distributing the work on the community).

EDIT:
You can also further test the master before building a release, by creating alpha, beta, gamma, and etc pre-releases.

1 Like
18

when it’s ready - we merge it (v3.7) back to master

Merging a release branch into master isn’t something we’ve ever done before.

I’m not familiar with the process you described. is it mandatory?

No, it’s not mandatory.

However, you said you wanted to learn about the process of creating a release. I think it’s important that you understand our customary process before you start proposing changes.

I’m not comfortable with merging features to master before they where even tested.

Some testing takes place in the feature branch before the pull request is integrated into master. Such testing is performed by the developer. Some issues slip through, so we test again prior to the first release containing the feature. Different testers uncover different issues.

Richtea asked:

cherry picking is only for rare features which miss the general branching for 3.7 but still want to be added late to the bus?

Cherry picking is for bug fixes that missed the release branch. Features are never cherry-picked.

In JME’s current scheme, creation of the release branch marks the “feature freeze” for the corresponding release.

2 Likes
19

Sure. this is the right path to take. I’ll learn the current process then suggest changes if I feel it can be done better.

1 Like
20

Hi Guys,
Can I assume that a PR created for merging a feature branch to master indicates that its owner thinks it is ready to be merged?
Also, I see this “Future release” label on some of the PRs. does it mean that this PR is approved for the next release?

image
image723×78 7.28 KB

Also - is there any indication in GitHub about how ready is a given PR to be merged? I see comments on some of them but some of them don’t have a reviewer assigned …

Thanks

1 Like