>>>> Reasoning for "No Version Number":
>>>> - Allows build.xml files that use these JARs to define properties
>>>> (commons-beanutils.jar=${commons-beanutils.home}/commons-beanutils.jar)
>>>> without worrying about version numbers
>>>> - We're going to maintain API stability, right? :-)
>>>> - Versioning information should be included in the MANIFEST.MF
>>>> file inside the JAR anyway, so it's redundant in the filename
>>>
>
> I actually like having the version number on the jar.
>
> Can't the build scripts assume a pattern :
>
> commons-<component>-<version>.jar
>
> and then deal with them that way, wildcarding the <version> part when
> you don't care?
>
> To try to relate a little about why I think this, I have noticed that
> people do some strange things, like putting all jars into one directory
> for easy access/replacement/copying. So when you are dealing with a
> problem, and you get told the classpath is :
>
>
>CLASSPATH=/opt/jars/commons-beanutils.jar:/opt/jars/commons-fubar.jar:/opt/jars/woogie.jar...
>
> you have no clue whats really going on, requreing another round-trip to
> dig into the manifest. It also means when logging in production, and
> you dump your classpath to log, you can't tell either. (No, I personally
> never depend upon classpaths if I can avoid it...)
>
> Anyway, I don't feel too strongly (have been away from commons for a
> bit, so just getting back up to speed on stuff) and agree that the
> proposal would make things neater, but there is some upside to the
> version in the filename, and I think if we can arrange for it to be
> dealt with via patterns and wildcards, things might be better.
>
Has there been a decision reached on this? I am +1 on including version
number in the jar, per Geir's suggestion, although I am not a committer.
Scott Sanders
