The SDK side of this is:
First of all: What we originally had was a little server/webspace where we had our custom maven repo and the netbeans update-repo.
With this gone, our jcenter maven repo lacks some jBullet and test-data, I guess. This part is up to the engine guys, the sdk currently simply builds the engine from source. I’ve heard that this is due to some Licensing/ToS (Since the jbullet.jar isn’t our code but 3rd party and test-data isn’t code at all)
We also miss our current update repository for netbeans/sdk updates but this is non-critical to engine releases (as actually anything sdk-related). I’m looking for a good solution and am evaluating bintray for this. I have to check their ToS.
Other than that, the SDK is fine and can even build the Engine from source.
The Problem here is only that we can’t/shouldn’t rely on any person, simply because we want something accessible by any team member easily. Any webspace/ssh access does not satisfy that criteria.
If that means Cherry Picking, then someone “simply” has to check every commit after the v3.1 branch was opened (and master became 3.2) to see if it is missing on v3.1 and if so, if it makes sence to have it.
For example we added PBRIsComing Branch to 3.2, that is a new feature and as such 3.1 unrelated.
Feel Free to search a bit and post the list on the Hub. I highly suggest you to use some graphical tool which shows the multiple branches (so you can see PRs and which was PBR and such).
When using SourceTree or comparable, cherry picking doesn’t even need fancy git commands. Other than possible merge conflicts it’s only about selecting a commit and a branch.
Now onto my personal opinion:
I don’t really understand why people are so focused on releases, especially on the actual name. I can only speak for JME but our Alpha Releases were simply at a fixed time on Sundays every 14 days. And so will be beta, etc.
Releases are only timestamps or pointers on commits at a given time. No-one can guarantee you that a release called stable is stable.
I’d rather use master and take the risk on experiencing some bugs because usually you have less bugs than on a fixed release because you have the latest possible version.
(I’m talking about the v3.1 Branch/master after alpha-1. When using 3.2 (which is currently master) you could always have some possible bugs introduced by new functionality or the functionality itself doesn’t yet work).
Keep this in mind: With 3.0 you have 0% chance of having the bug fixed, but with master, it’s only one Pull Request away 
This brings me to what I think could always help: There are so many people which don’t report the issues they come across if they find a suitable workaround. I know it takes time but that is what let us improve our engine.
What’s also important is contribution via Pull-Requests: If you had to implement something new which the Engine doesn’t offer, don’t hesitate to contact us about how we could integrate it into the engine or rather if it’s useful to be added to the engine.
This is what I believe a reason for the stalling a bit. We don’t have that much activity lately because no-ones reports an issue so no-one can fix an issue. (Maybe that’s a sign that it becomes more stable? 
)
I recently fixed the iOS Deployment (it still has issues), but there is only one user actively needing it/testing it out, so those issues stayed there for like a year.
So my advice would be: Simply use master (or rather v3.1 branch) and simply report the issues you might get. I think you can safely consider this “3.1-beta2”, given the time and bugfixes that have passed since.
Also since you are doing an MMORPG for which you need to know your engine tightly, you might be able to fix some issues you’d encounter and contribute them via Pull Requests. That would be the most helpful actually. Most issues are simple ones, you only have to find the root 
