Versioning is there for a reason - for example it prevents silly mistakes. I'm aware some people even agree that version numbers should increment in some way. If you've already released version 1.0 of your code, its a good idea for the next version to be something like 1.0.1 or 1.1 or 2.0.

The key point here is that the next version number is different to the previous version and, if possible, a higher number than the last one.

I'm not claiming any higher insight or best practice here, I'm just hoping that it makes reasonable sense. Besides, others have already written about this.

If your software is packaged as a Java jar, you could also publish this to a public maven repository. That would be a helpful bonus. I could reference your repository in my configuration and pull the dependency as required.

Do no evil

Google however doesn't always think in this way. For example, gdata-core-1.0.jar was released in 2009 then followed by the next release gdata-core-1.0-jar in 2011. Some would say that this is a little confusing. It has had me confused. Initially, I thought that their documentation was pure lies. None of the methods documented were available in the software I was using. After a while, I found out about the 2011 vintage of the code. As you can imagine, I was very excited by this curious discovery, using some very choice words to describe Google's engineers.

The good news was that the code and the documentation now actually matched.

Code examples work well with the 2011 vintage, but the 2009 vintage throws errors such as

java.lang.NoSuchFieldError: V2_1

	at com.google.gdata.client.analytics.AnalyticsService$Versions.<clinit>(AnalyticsService.java:69)

	at com.google.gdata.client.analytics.AnalyticsService.<clinit>(AnalyticsService.java:88)

Another tip: Don't let the 2009 vintage of gdata-code-1.0.jar get anywhere near your build server. Take it from me, it's a bad idea.