Should this be dusted a little? I know it’s like priority -9000 but it’s 2014 now, not 2012 and also, 3.0 never shows the actual build revision or minor version, it should show that I think 
JUST MY 2 CENTS haha I’m sorry for stealing 9 seconds of your day lol, you will never get them back! muahahahaha
The application itself gets updated via the update center, the plugins show you the minor version, the application only gets updated on major versions (3.1). But we could up the date at some point yeah 
I can’t be bothered to fire up photoshop, tack an extra number on there and send that to Normen every time we need to do a patch release, sorry 
As for the things that don’t require me to do anything, I wholeheartedly agree, we should do something about those!
2012 → 2014
http://www.jmonkeyengine.com → http://jmonkeyengine.org
@erlend_sh said: I can't be bothered to fire up photoshop, tack an extra number on there and send that to Normen every time we need to do a patch release, sorry :P
If only you knew some graphics programmers that could generate that image from the build info 
Aww, no, we want a shiny new image and a new monkey with every major version And as said, the minor versions will never appear in the application name or splash.
Well couldn’t that text be rendered as an overlay?
Then the version determined by the new gradle build could be used, and no changes to the image needs to be done for this.
Yes but it doesn’t need to be as we will make a new image on every major release anyway and the minor release numbers don’t go on that image.
^^ Fair enough^^, how about a System.currentTime() for the copyright year then XD
@normen said: Yes but it doesn't need to be as we will make a new image on every major release anyway and the minor release numbers don't go on that image.
Just for clarification; version numbers are 3.<MAJOR>.<MINOR>?
And also
@jmaasing said: Just for clarification; version numbers are 3.<MAJOR>.<MINOR>?And also
ImageMagick v6 Examples
Yes. Its much like OSX’s versioning scheme, we explain it here:
http://hub.jmonkeyengine.org/2011/10/jmonkeyengine3-sdk-beta-released/
@Empire Phoenix said: how about a System.currentTime() for the copyright year then XD :P
LOL’ed 
That’s what I do on every website footers, no need to open up 200 websites every year to change this number
@normen said: Yes. Its much like OSX's versioning scheme
Well, OSX puts the minor version in the ABOUT screen tough 
Just sayin’
BTW I had underlined the top right corner SDK 3.0 STABLE but I forgot to mention in my OP that this was taken on the edge nightly build, so… maybe we could have a note whenever it’s the nightly build and also on the splash loading screen when we launch it. I personally changed the icon too just to make sure I don’t get mixed up between the two!
Like this:
OH and just one last thing to whine about lol… could we have the nightly build compiled under a different program name than jmonkeyplatform64.exe because whenever I tried to make Windows open some file types with the nightly build by default, it would always open them still with the stable jmonkeyplatform64.exe app, thinking both are the same. Windows is stupid like that, doesn’t care for the .exe path at all. Same name? Same program. :-/ Even if I went to “BROWSE…” and manually select the “C:\Program Files\jmonkeyplatform-nightly\bin\jmonkeyplatform64.exe” app, it would still think it’s the stable version. Kind of annoying
Thx!
Again, the application only has a major version because the application cannot be updated via the update center, it will only be updated with major versions. This is also why the splash screen doesn’t change and why the version in the about screen will stay as it is. The plugins contain the minor version info, you can check the minor version in the plugins window.
I am thinking about removing the nightly option from the normal SDK and only allow the nightly to be used in a separate SDK download. Then we could also change the executable name. But… what kinds of files do you open with the SDK anyway?
Material definitions, classes code, vertex and fragment shader files, etc… What I do now is drag and drop, but it’s annoying.
EDIT: inb4 Ben, why don’t you just uninstall the STABLE 3.0 SDK in short? Well… I want to use both, not at the same time of course, but back and forth between the two, since the nightly could get broken at some point for a period of time so I want to still have a plan B you know?
@.Ben. said: since the nightly could get broken at some point for a period of time so I want to still have a plan B you know?
If it does, revert to the last commit where it’s not crapping out? #SimpleSolution
@madjack, I know lol… plus it never did in the last months for me anyway so I’m not afraid about that
I guess I could uninstall the STABLE 3.0 SDK lol… I’ve not used it in like 2 months now.
Do you guys only have the nightly build installed on your computers or have both?
@.Ben. said: @madjack, I know lol... plus it never did in the last months for me anyway so I'm not afraid about that :PI guess I could uninstall the STABLE 3.0 SDK lol… I’ve not used it in like 2 months now.
Do you guys only have the nightly build installed on your computers or have both?
Theres no way to go back to some version without building it yourself. And especially from now on the nightly will break constantly. Theres no good reason to use nightly unless you develop the engine itself really.
I had to install nightly a couple months ago because it fixed bugs for a new plugin that was being developped. It wouldn’t work unless I had edge at that time. Until the STABLE 3.1 SDK is out, that’s a very very long gap I would have had to wait. I didn’t want to wait
@.Ben. said: I had to install nightly a couple months ago because it fixed bugs for a new plugin that was being developped. It wouldn't work unless I had edge at that time. Until the STABLE 3.1 SDK is out, that's a very very long gap I would have had to wait. I didn't want to wait :D
Right now all plugins compile against stable.