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

Discussion in 'Java' started by Chris, Sep 5, 2006.

  1. Chris

    Chris Guest

    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.
    Chris, Sep 5, 2006
    #1
    1. Advertising

  2. Chris wrote:
    > 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
    =?ISO-8859-1?Q?Arne_Vajh=F8j?=, Sep 6, 2006
    #2
    1. Advertising

  3. Chris wrote:
    > 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?
    Brandon McCombs, Sep 6, 2006
    #3
  4. On 06.09.2006 04:33, Brandon McCombs wrote:
    > Chris wrote:
    >> 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?


    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
    Robert Klemme, Sep 6, 2006
    #4
  5. Chris

    Chris Uppal Guest

    Brandon McCombs wrote:

    > 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
    Chris Uppal, Sep 6, 2006
    #5
  6. Chris <> writes:

    > 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.
    Tor Iver Wilhelmsen, Sep 6, 2006
    #6
  7. Chris

    Tom Cole Guest

    Chris wrote:
    > 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.

    > What's the better approach? I've seen it done both ways.
    Tom Cole, Sep 6, 2006
    #7
  8. Chris

    David Segall Guest

    Chris <> wrote:

    >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.
    David Segall, Sep 6, 2006
    #8
  9. Chris

    Guest

    Chris wrote:
    > 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
    , Sep 7, 2006
    #9
  10. David Segall wrote:
    > Chris <> wrote:
    >
    >> 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.


    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
    Patricia Shanahan, Sep 7, 2006
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Arnold Peters
    Replies:
    0
    Views:
    564
    Arnold Peters
    Jan 5, 2005
  2. muttley
    Replies:
    0
    Views:
    2,714
    muttley
    Oct 20, 2005
  3. V Green
    Replies:
    0
    Views:
    840
    V Green
    Feb 5, 2008
  4. PA Bear [MS MVP]
    Replies:
    0
    Views:
    952
    PA Bear [MS MVP]
    Feb 5, 2008
  5. laredotornado
    Replies:
    23
    Views:
    1,270
    Arne Vajhøj
    Jan 26, 2011
Loading...

Share This Page