Opinions, please - include version # in jar file name?

[Chris]

We distribute an app as a library. The core of it is a single .jar file.

We have been including the version # in the name of the jar, i.e.
myapp-1.2.3.jar

Is this a good idea? On the one hand, it makes it very easy for the user
to see what version they have. On the other hand, the user has to update
the version number in the classpath for the startup script every time we
have a new release.

What's the better approach? I've seen it done both ways.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

We distribute an app as a library. The core of it is a single .jar file.

We have been including the version # in the name of the jar, i.e.
myapp-1.2.3.jar

Is this a good idea? On the one hand, it makes it very easy for the user
to see what version they have. On the other hand, the user has to update
the version number in the classpath for the startup script every time we
have a new release.

What's the better approach? I've seen it done both ways.

As you say there are pros and cons for both.

I tend to prefer no version numbers personally.

To avoid lazy people dumping a new jar into the classpath
without getting the old out and creating a version mess.

Arne

 

[Brandon McCombs]

We distribute an app as a library. The core of it is a single .jar file.

We have been including the version # in the name of the jar, i.e.
myapp-1.2.3.jar

Is this a good idea? On the one hand, it makes it very easy for the user
to see what version they have. On the other hand, the user has to update
the version number in the classpath for the startup script every time we
have a new release.

What's the better approach? I've seen it done both ways.

Why not put the version number in the title of the main JFrame so people
can see it all the time while the app is running but not have to worry
about making sure their classpath is always correct?

 

[Robert Klemme]

Why not put the version number in the title of the main JFrame so people
can see it all the time while the app is running but not have to worry
about making sure their classpath is always correct?

I'd put the version number in the manifest - if there is a reasonable
place in the UI I'd put it there additionally. And, yes, I also prefer
to not have it in the JAR name. My 0.02EUR

Kind regards

robert

 

[Chris Uppal]

Why not put the version number in the title of the main JFrame so people
can see it all the time while the app is running but not have to worry
about making sure their classpath is always correct?

Some of the Apache/Jakarta libraries have a static
aaa.bbb.Version.main(string[] args)
embedded in each jar file. That function just prints the version info to
stdout. Makes it easy to get version info out of a JAR without programming or
unpacking it (if you know it's there ;-)

There may even be more than one such in the same JAR.

-- chris

 

[Tor Iver Wilhelmsen]

We have been including the version # in the name of the jar, i.e.
myapp-1.2.3.jar

Is this a good idea?

Having been bitten by multi-developer projects using expanded
classpath variables that pointed to a different version of a lib for
user A than for user B, I think it's annoying.

In Unix-variants you can have a soft link pointing to the "default"
implementation and use that name (sans version number) for stable
releases and the explicit versioned files for development, testing or
using prior versions.

Ideally, the classpath issue should be solved using either the
manifest Classpath entry for java -jar type invocation, the
dependencies in a JNLP application or some other dynamic configuration
method. So that the end user doesn't need to worry about it.

 

[Tom Cole]

We distribute an app as a library. The core of it is a single .jar file.

We have been including the version # in the name of the jar, i.e.
myapp-1.2.3.jar

Is this a good idea? On the one hand, it makes it very easy for the user
to see what version they have. On the other hand, the user has to update
the version number in the classpath for the startup script every time we
have a new release.

I would say:

1. No version number on the .jar file.
2. Distribute as a .zip not a .jar and include the .jar and a read-me
file. This read-me should contain any changes since the last version
including version number.

This also requires that they take an extra step and think about what
they're doing before they just plop the .jar in the same old place.

My $.02.

 

[David Segall]

We distribute an app as a library. The core of it is a single .jar file.

We have been including the version # in the name of the jar, i.e.
myapp-1.2.3.jar

Is this a good idea? On the one hand, it makes it very easy for the user
to see what version they have. On the other hand, the user has to update
the version number in the classpath for the startup script every time we
have a new release.

What's the better approach? I've seen it done both ways.

If you follow Sun's example for the JDK and JRE the version number
should be included in the name. On the other hand, I have often cursed
myself for upgrading to a new version, deleting the old one and then
omitting to update some application that needs to know. I now install
the new version and copy the upgrade to a similarly named location
that does not append the version number. I can see why Sun include the
version number but unless your application may need to be run using an
old version I think that every version should overwrite the old one.
Of course, the current version number should be in some easily
accessed location.

 

[pkriens]

We distribute an app as a library. The core of it is a single .jar file.

We have been including the version # in the name of the jar, i.e.
myapp-1.2.3.jar

Is this a good idea? On the one hand, it makes it very easy for the user
to see what version they have. On the other hand, the user has to update
the version number in the classpath for the startup script every time we
have a new release.

What's the better approach? I've seen it done both ways.

Depends on how you use your version numbers ...

The OSGi Alliance has defined extensive manifest meta data for JARs.
They define a version as

major.minor.micro.qualifier e.g 1, 1.2, 1.2.3, 1.2.3.v200603041000

Micro is bug fixes, minor is backward compatible, and major is a break
in compatibility. The release 4 specification allows multiple versions
of the same JAR in a single VM.

To answer your questions, if you want to support multiple versions in a
VM, using the major and micro in the jar name makes sense. If you work
in a normal Java environment, just using the major number should be
sufficient.

Kind regards,

Peter Kriens

 

[Patricia Shanahan]

If you follow Sun's example for the JDK and JRE the version number
should be included in the name. On the other hand, I have often cursed
myself for upgrading to a new version, deleting the old one and then
omitting to update some application that needs to know. I now install
the new version and copy the upgrade to a similarly named location
that does not append the version number. I can see why Sun include the
version number but unless your application may need to be run using an
old version I think that every version should overwrite the old one.
Of course, the current version number should be in some easily
accessed location.

Does this make sense?

If multiple versions need to co-exist on the same machine at the same
time, including the version number may reduce confusion.

On the other hand, if the normal upgrade is to replace the old instance
of the application, then including the version number gets in the way.

Patricia