Hello fellow java progammers! this might sound like a weird question but how do you guys increment your software versions? If you were just releasing a bug would u change it from 1 to 1.01 or something else? Or have any of you created a system for this? Any ideas are welcome!

On Unix you often find schemes like <major>.<minor>.<patch> where patches are bug fixes, minor are minor changes, and major, well are major changes.

On Windows you often see something like <major>.<minor><a...z> where a-z denotes fixes, minor and major work just like above.

I've got tired of all that and just count releases. Starting with 001 and going up each times I publish a new version regardles how big or small the changes are ... often I write that as 0.01 but actually I just count releases these days.

so you mean:
how to allow to your application to verify if there are new version of your software and how to automatically download and update it?

Semantic Versioning is a standard someone proposed for versioning. I don't know how well it has taken hold but Google does give up some hits (as well as some stackoverflow question/answers). It makes sense to me, but it's overkill for what I need.

I think the key question is, who is the real audience for the version number? If it's just you banging away on your project, then I don't think version numbers are all that necessary and you can simply keep track of things through your version control tool (you are using version control, right? Right? RIGHT?!?!). Although I can see the mental component of slowly rising version numbers as a barometer of progress being motivating.

Ah, I was thinking you meant it in some semantic sense, like "how do you make your program aware of the new version".  Sometimes I just read too much into questions

Anyway, my answer is, I use maven and sbt so I just update the version field in the build definition, by hand sometime before the next release.  I'm never all that good about doing it first thing after a new release, but no one notices because I don't release daily snapshots either.  I follow semantic versioning of major.minor.patch, which is more or less industry standard.  I do tend to draw a fuzzy line between "minor version" and "patch level", and don't use patchlevel that much, to be honest.  After accumulating enough bugfixes I just bump the minor version, since I like releases to always be on a .0 version.  If I have to deploy a patchlevel release into production, it's because something went seriously wrong that can't wait. 

I have a manually updated number in an ant build script that I just increment, but I also export the svn revision number and burn that into the jar as well. The manual number covers 'big' changes and proper releases, the svn number is there so that I can easily see if someone's using a bug-fixed version or not. And also because sometimes I forget to update the manual number.

While I generally agree, when I was doing Tectonicus and suddenly ended up with loads of users, I found a major version number really handy. People generally understand that '0.xxx' means 'not quite finished and probably buggy'. And when I did a major breaking change that meant everyone had to change their config files and scripts etc. it was really handy being able to switch from 1.xxx to 2.xxx.

Other than the major version, the minor was just an incremented number as you say.

I just do it like this:

<major>.<minor>.<extra minor>

(extra minor is a thing that can not be called a minor change (if too small, for example)).