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.
>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? ;) 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.
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 |
*-----------------------------------------------------*
