The first INFO log message from jME is:
INFO: Running on jMonkeyEngine 3.0.0 Beta
It would be nice if the message actually said:
INFO: Running on jMonkeyEngine 3.0.0 Beta, Build number 12345
We will have proper version numbers from release on, like 3.0.1, nightly builds will be strongly discouraged from release on. Nightly builds are named in the SDK plugin manager, there you can see what version you use. If you download the svn manually we kind of expect you to know what version you downloaded.
The build number (SVN revision) is helpful for situations where the software runs on a player machine.
Release numbers and what’s actually in it can get out of sync due to all kinds of mishaps. SVN revisions cannot (usually).
@toolforger said: The build number (SVN revision) is helpful for situations where the software runs on a player machine. Release numbers and what's actually in it can get out of sync due to all kinds of mishaps. SVN revisions cannot (usually).
Personally, I include my application’s build time in such log messages. The core libraries I include are then sort of ancillary.
I can provide the little snippet of build.xml cod I use to generate the build time file if anyone is interested.
Yes they are ancillary.
In practice, sometimes you want to make sure that that user is really having the version of the library that you think he should have. After all, records of which build of what library went into which version of your game could have gotten mixed up.
Oh, and I’d like to see your XML, thanks.
Well with the svn version the problem starts that there is no real way to get it.
Most developers put versions on their applications and know what library versions these use 
Unless you let your “user” add the libraries himself I don’t see how theres a chance that the user would have to tell you what version of some library he has?
@toolforger said: Yes they are ancillary. In practice, sometimes you want to make sure that that user is really having the version of the library that you think he should have. After all, records of which build of what library went into which version of your game could have gotten mixed up.Oh, and I’d like to see your XML, thanks.
Let’s see if the forum eats it:
[java]
<property name="application.title" value="Mythruna-${build.date}"/>
<echo message="${build.date}" file="build/classes/build.date" />
</target>
[/java]
I can then load the /build.date resource to get the information. I reset my application title so that the build date is included in the generated .zip files but it can be left out, of course.
Hilarious… here is the properly formatted version as an image:
I just include this in my build.xml file in the project root.
Hm… well, I was after the SVN version, not the build date, but thanks anyway.
(Sorry for the late response, we’re currently vacationing in Portugal and the Wifi is rather bad.)
@toolforger said: Hm... well, I was after the SVN version, not the build date, but thanks anyway.(Sorry for the late response, we’re currently vacationing in Portugal and the Wifi is rather bad.)
…the build date can be used to determine the SVN version and is easily generated. You can even include time if you want it to be more accurate.
Do you generate that during build or during commit?
@toolforger said: Do you generate that during build or during commit?
During build. But my releases are always committed before I build them.
You can look at SVN history by revision or by date+time.
Hm… my build process is the other way round: I build, do the manual tests, then commit.
So the commit may happen hours after the build, which makes the association from build time to SVN revision somewhat tenuous. Going from SVN rev to date is going to be correct no matter what, so I’d prefer it to go that way.
I’m just seeing that SVN doesn’t make it easy to set that up. There’s keyword substitution but it won’t happen in the local copy unless you do another svn update, and $Revision$ covers only the lastest modifying revision of the current file so you need some scripting.
Pity. I had though it would be easy to slap that on.
@toolforger said: Hm... my build process is the other way round: I build, do the manual tests, then commit.
…and then it seems like there is no way to safely inject a version into your already packaged build, anyway.
A “proper” release build in a formalized environment is:
-develop until code is right for that release
-commit it
-tag/branch it
-build/release from the tag. (to make sure the tag actually has what’s needed)
-smoke test the release
I tend to go with shortened lifecycle but it would still make me feel very dirty to do my final release build against uncommitted code. It means that it is possible for the build to be unreproducible given the change that changes can occur between build and commit.
$Revision$ IS a safe way to inject a revision number 
Just make sure that the file containing it contains nothing that would be modified outside release preparation. Say, use a version.properties file like this:
release=1.17
revision=$Revision: 4536$
Then the version.properties file will always hold the revision number of the release, just do an SVN update after the commit.
You’d probably:
- do the last normal commit
- branch
- bump the release number in version.properties
- svn update to get the modified $Revision$ value
- build
- smoke test
- release
- merge branch back into trunk
… okay, tagging would work, too. Just make sure you modify the version.properties file, commit it, and do the svn update, so you get the new revision number into the pre-release build. It’s cosmetically a bit less desirable because that’s going to leave gaps in the release numbering scheme, and people get irritated by that.
Technically, you could do some cosmetic change in version.properties to force the revision number update, but that feels dirty, too.
I tried to come up with something that uses svnversion, but that involves another commit, which would (rightfully) fail if others have committed in the mean time, so you’d still need to branch.
I guess making a branch is indispensable in a multi-developer situation, and cosmetically desirable in a single-developer version