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!
It’s just a filename for your jar. Java has no concept of library or program versions. It usually depends on your build software – if you’re using maven, you update the in the POM.
On Unix you often find schemes like .. where patches are bug fixes, minor are minor changes, and major, well are major changes.
On Windows you often see something like .<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.
Lol not what i mean…
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?
versionNumber++;
;D
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.
whatever you want. right now i’m just on revisions because none of my stuff is truly out yet. A really good one would be to set it to a decimal representing how complete it is.
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 didnt yet include this in my build scripts, but one way is to generate a “build number” for each time you build (i.e. compile) the application. The application then shows this build number in the main menu or while starting up (e.g. “build 435”). Sometimes you release a new build, then it’s clear for everyone involved what version the application precisely is, and whether they have the latest version (build number). I never understood the majorversion.minorversion.evenmoreminorversion.extremelyminorchangeversion approach to application version numbering. It’s quite involved, prone to errors, and generally doesn’t really say anything.
See: http://ant.apache.org/manual/Tasks/buildnumber.html for how to do this in Ant.
Edit: updated the link with better info.
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.
I go with Varkas’s, except it’s . since I rarely push new release with minor changes.
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.
At work we like to use the mercurial hash tag for versioning information, because that way we can easily reconstruct the software from the versioning system. But of course we could assign something like “2.3.0” tag to it, but whatever.
Of course a string like “df894hfd9jl489d” makes no sense, because it doesn’t indicate which version is more recent.
But IMO the format of the versioning doesn’t matter as much as long as you can translate that to a certain version of your software, like in a versioning system. And also, using an incremental number is helpful for everyone.
I just do it like this:
..
(extra minor is a thing that can not be called a minor change (if too small, for example)).