On Sat, 5 May 2001, Peter Donald wrote:
> At 09:52 4/5/01 -0700, Craig R. McClanahan wrote:
> >IMHO version information belongs *inside* the JAR's MANIFEST.MF file
> >(where it can be checked by tools), not outside. We're already doing
> >that, and CJAN etc. can certainly be programmed to extract that and
> >display it on the download pages.
>
> Thats not te issue as I see it. The reason I see it is that without
> versioning you can only have one version sitting side by side. So you could
> theoretically have both a 1.0 and 2.0 in same directory if you need it.
>
The fundamental organizing principle (common since almost the beginning
with Jakarta releases) is that the version number is included in the name
of the binary distribution packages (jakarta-foo-1.5.tar.gz) as well as
the name of the directory into which those packages unpack themselves
(jakarta-foo-1.5). This lets us define appropriate build.properties
entries for your different projects:
foo.jar=/usr/local/jakarta-foo-1.5/foo.jar
where you need version 1.5, or (if you need 1.6):
foo.jar=/usr/local/jakarta-foo-1.6/foo.jar
Given that we have to do something like this even if I have foo-1.5.jar
and foo-1.6.jar (in the same directory or not doesn't really matter),
having the version numbers in the filename does not buy you anything.
> >I also note the precedent of standard Java packages -- take JAXP for
> >example, where "jaxp.jar" and "crimson.jar" do not have version numbers in
> >the filenames -- as well as many other packages (Xerces does the same
> >thing).
>
> true - but how much pain did that cause?
That didn't cause any pain. Changing the release file from "parserjar" to
"crimson.jar" caused a small amount of pain (otherwise, I would have just
needed to change my definition for "jaxp.home".
Switching Xerces versions is equally easy. For example, I define the
following:
xerces.home=/usr/local/xerces-1_3_1
xerces.jar=${xerces.home}/xerces.jar
and I only need to change "xerces.home" to switch to a new version.
;) I guess the closest thing in
> the more mature native world is looking at .dll/.so naming. In most cases
> it is fine to have them unversioned if they are in an application local
> directory. However if they live in a centralized directory they should have
> version embedded - if they don't you end up withh DLL at every update.
> ".so" files are a little easier to use as you can easily have multiple
> versions on filesystem.
>
Using .so files works because the OS supports symlinks, and conventional
shared library installation leverages them -- which allow an application
to use a non-versioned filename to get the default, and only have to care
about version numbers if it wants to. Installing an updated library
requires zero changes in the scripts for applications that simply
use the defaults, courtesy of not having versions in the paths they use.
> Cheers,
>
> Pete
>
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof." |
> | - John Kenneth Galbraith |
> *-----------------------------------------------------*
>
>
Craig
