At 11:37 5/5/01 -0400, Geir Magnusson Jr. wrote:
>How would you summarize your position re versioned jar filenames? I
>think I understood that you do see some benefits - the utility of .so
>versioning compared to .dll hell...
Well - I see both the beenfits and penalties of it. It is probably best to
describe the use case I find comfortabele and let you derive your own
conclusions ;)
If I was a pure user (not a developer at all) I would prefer verioned
filenames. Then they could be installed in one central directory and even
programs with incompatible libraries (ie cocoon1 vs cocoon2, SAX1 vs SAX2,
DOM1 vs DOM2 etc) could live in harmony. So seeing something like
sax-1.0.1.jar
sax-2.0.jar
xerces-1.1.jar
xerces-1.2.jar
xerces-2.1.jar
would be possible and all programs could live happily together.
If I was a developer who only used stable versions which had a low
frequency of updates then I would prefer versioning to be marked in
filename. For instance in avalon all the xerces/xalan/stylebook jars have
versions embedded in names as I rarely update them.
For libraries that have a high frequency of change I HATE version embedded
in names. For instance in avalon we use unadorned names for our separate
libraries. ie logkit.jar, avalon-framework.jar, avalon-excalibur.jar,
testlet.jar etc.
As some of these can be updated a few times in a busy week it is painful to
maintain versions/dates embedded in jar names.
So essentially anything I rely on CVS versions to run I want no versioning
while stuff I download from web I want version embedded in names. When we
do a stable release of avalons stuff we plan to embed the version into
filenames - until then we go unversioned.
Not sure if that helps ;)
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 |
*-----------------------------------------------------*
