Yeah okay, the banana thing was a a little bit to much creativity (got an overdose of the monthy python sketch “self defense course” ^^ ).
So I would propose only the monkey names.
<cite>@zarch said:</cite> ("what's the catch?")
You may have to deal with normen at some point 
jME3 - We eat Poo for breakfast
I had the random idea of word + monkey
like
-dancing monkey
-bouncing monkey
-…
@zarch said: Can you seriously see someone standing up in a business meeting and saying "we are going to use jMonkeyEngine 3: Gorilla 2nd banana" with a straight face?
I actually agree but this conjured an image in my mind…
Guy standing up in a business meeting: “We’ve had none of the problems we had with Gingerbread and managed to get Ice Cream Sandwich done and now we’re just finishing up Jelly Bean.”
…no one would ever use such ridiculous names. 
<cite>@pspeed said:</cite> I actually agree but this conjured an image in my mind...Guy standing up in a business meeting: “We’ve had none of the problems we had with Gingerbread and managed to get Ice Cream Sandwich done and now we’re just finishing up Jelly Bean.”
…no one would ever use such ridiculous names.
It’s true, but don’t forget who’s use these names. They already do huge projects and now can take a funny path.
Well a “proper” version number AND a codename would leave the option for those humorless managers to use the numbers and for the cool coders to use the codename 
Before thinking about releasing a stable version I would think of solving the problem with motion paths and curves interpolation. Otherwise the word "stable"is meaningless.
<cite>@luke1985 said:</cite> Before thinking about releasing a stable version I would think of solving the problem with motion paths and curves interpolation. Otherwise the word "stable"is meaningless.What's the issue?
The issue is that the interpolation is wrong with almost every type of spline object in the engine - it’s not linear. Also the bezier curves made from more than 2 control points interpolation results in points that are not on the curve. I don’t want to go into details because there are posts dedicated to this topic. What I want to say is that it is a big drawback, and maybe disappointing for someone who expects a stable release to handle the engine features the correct way. It may discourage users from continuing with JME.
I don’t know but there may be more such unsolved issues. They were very annoying for me using Release Candidate. Leaving things as is in a stable will probably break users trust in future releases.
Well I’m not a developer so things don’t belong to me though.
If You ask me how could i call the next stable, I would call it “Chico” 
Well fell free to post a patch mister clever.
For a free to use complete 3D engine the developers of jm3 have done an awesome work. Search arround for other 3D engines, there are very few as mature engines as jm3 is. In java there is just an offspring that shows some promise but looks like its development is very very slow. In other languages most of the time you have to resort to do a lot of the stuff jm3 does for you on your own. So even if there are some issues and bugs in a release (and NO software ever was without!) i doubt that putting a stable release out even if there still are some known issues will make the users unsecure. You can see that a lot of work is still done and that issues will get fixed in time, and for a developer team that does this thing in their free time this is an awesome piece of work.
While I feel that a 3.0 Stable deserves an awesome name, I would prefer a linear sequence of build numbers:
Major.minor.build
3.0.345222
Then there is no confusion about who is running what version. But still, JME is great software and the landmark needs to be marked, so I would like to see the first line of my logs read:
3.0.4534535 Bonobo
Because I like Bonobos, even though they are not really monkeys.
3 Likes
Read the last release post on versioning, this is about a name. If you think bashing the software just because you can see the source is a good idea, well go ahead. You can easily fool yourself into believeing that UDK and Unity are not as bugged as they are ^^ And obviously our “customers” (as if we’d get any money) trust us in fixing bugs as much as we trust in them finding them… And not being cocky about it.
I like ags1’s proposal. Works.
What I’m wondering is how to get the “awesome” in. Just monkey species names isn’t awesome (unfortunately).
… hmmmmm… maybe adding a picture of an awesome specimen is. E.g. google for, say, “awesome lemur”, and show the best image on the release announcement. If the image is awesome enough, it the connection between the image and JME will go viral.
I feel that discussing how a code name looks like when in context with a version number is on-topic, discusing whether there should be a build number is off-topic.
Unrelated afterthought: I just found a list of fictional monkeys, so if the mythical beasts are still unter consideration, here it is:
1 Like
How about giving it names from fantasy inspired common game elements items, like
“Pixie Dust”
“Rusty Dagger”
“Golden Key”
“Mana Potion”
“Toad Eye”
“Developers’ Tear” ( wink )
“Adventurers boots”
“Ghost blood”
“Bag of Holding”
“Giant’s Toe”
“Storm in a Bottle”
“Pandora’s Box”
This naming scheme, has no limit in creativity, making sure that we will not have akward names in late versions of jME, when “all the cool monkey names are taken”. Eventually you can just move on to more and more epic items, like “Balrog Whip” or “Aegis Shield” or “Deus Ex Machina”. Also it breaks the “monkey-theme” a bit, and underlines that jME is a game engine.
1 Like
I like @nihal’s proposal
I do too, although rusty has the wrong connotations
I will stay away from the “Grue” release.
<cite>@zarch said:</cite> I do too, although rusty has the wrong connotations :)Hah, yes, I was not serious about all the suggestions, maybe "Flaming Dagger" would be more appropriate. Just googling an item wiki of any major rpg gives alot of inspiration.
I guess the very final version of jME ( if there ever was such a thing ) could be called the Unstoppable Force or the Immovable Object…?
…can the developer make an object so immovable that even he cannot move it?