Probably there aren't enough features in JME2 to justify a whole new version, certainly compared with how long it took for version 1 to be released.
However, that naming decision is long in the past now. What most people are working with is for better or worse known as JME2. It's detrimental to the project for that to be referred to as not final, not stable, not whatever. People are left thinking… you're telling me JME1 is out of date, and JME 2 is not stable - so basically there is no solid JME version?
Certainly it seems highly unlikely that a JME3 is realistic in the near future. But what we have is solid and viable, and not JME1. So let's start referring to it as such.
darkfrog said:
I don't have a problem with releasing 2.0 presuming that additional development is going towards 2.1 and not a 3.0. I think it's a very bad idea to push out a version just to try to get people excited about something. I say, get more features and functionality and people are more likely to be excited than an arbitrary statement of "hey, this is stable and we assigned a pretty number to it". :-p
A stable 2.0 is required, since lots of people work with it now and want to build an app on it, and dont want trouble with stability issues. There was a huge effort put into making 2.0 stable, it would be silly to break it now. Don't care whether the new version is called 2.1 or even 3.0, if we (i hope i get the chance to rewrite the core geometry and shader support) get a new branch to work on. There are a number of people on this board who have shown that they understand the internals and the whole of the engine. Lets get those people together, to agree on the way features should be implemented, and who will implement what.
I don't have a problem with releasing 2.0 presuming that additional development is going towards 2.1 and not a 3.0.
I think thats the whole idea alrighty :). To make the 'current' version stable (final) so there can be a better push towards a 2.1 (or even 3.0) without having to worry we are gonna break someone's code with changes (or I guess so we can be un-encumbered by not having to worry about changes breaking someones code...).
So people don't get caught up arguing about version numbers I would like to clarify. In my original post, 2.1 (and subsequent 2.2, 2.3 …) is referring to tags in a maintenance branch for 2.0, so that while major changes are going into the trunk (for 3.0 or whatever number we want to give to it) we can still effectively address any issue that may arise after 2.0 release. We can number it however we all agree is appropriate, I'm just trying to communicate an outline.
That's some good clarity right there 
When will 2.0 be final then, currently there only two issues marked "Release2.0"
When those are fixed we should enter some release phase, right? And we should start thinking about what goes into the trunk and all that…
dunno who is responsible for that nowdays, but i should probably not be moderator for some of the forum areas
I have updated the copyright task, so now there is only "Create changelog"; however I wonder how big the scope of this task would be if it includes all the changes from 1.0 to current…
nymon said:
gouessej said:
Could the issue 24 be fixed in the release 2.0 instead of 2.1? I'm really sorry, I investigated some days but I didn't succeed in finding a fix.
I will take a stab at it this week.
Have you found something? Even the display is wrong when using the class FirstPersonHandler in the JOGL renderer, it is becoming extremely annoying :'( I wanted to prepare a webstartable blue print but is it worth with so many bugs (the mouse works only when a mouse button is pressed, there is some flickering when I move...)? it won't be a FPS, rather a SPS (shit person shooter) :x I'm still investigating but I have almost explored all possible tracks of root cause that I know and I don't really understand why TUER works but when I do almost the same thing with JME 2.0 and the JOGL renderer, it doesn't work as expected.