And here are some counter points: * With version numbers, you're not precluding users from partitioning their libraries into directories, whereas without version numbers, you're forcing them to.
* With version numbers, users immediately know which version they're using without having to compare file size or extract some META-INF files to know its version -- let's go for simplicity. * The argument that you have to update your library dependencies is a weak one, imho. I had to do it with a Pivot app I wrote, and it was a 2 second change that I only undertake when I upgrade to a new Pivot version, which won't be all that often. And larger, more enterprise applications use frameworks like Maven to manage their dependencies, so they don't have to worry about "updating their classpath in all of their build and deployment environments" either. And along those lines, Maven requires participating libraries to put their version numbers in there, so by not doing so, we're precluding our users from using Pivot in a Maven repository without modifying our distribution structure. -T On Fri, Mar 27, 2009 at 11:25 AM, Greg Brown <[email protected]> wrote: > One additional consideration. If the goal in embedding version numbers in the > JAR file name is to help manage different installed versions, I'd suggest > that an approach like the following is preferable. Each of the following > would be a directory containing pivot-core.jar, pivot-wtk.jar, etc. (without > embedded version numbers), and apache-pivot would be a symbolic link to the > directory for the "current" version: > > apache-pivot->apache-pivot-1.1 > apache-pivot-1.0 > apache-pivot-1.0.1 > apache-pivot-1.1 > apache-pivot-1.2 > > This is effectively how Mac OSX manages system libraries. > > On Friday, March 27, 2009, at 11:18AM, "Greg Brown" <[email protected]> wrote: >>-1 >> >>All, please consider the impact such a change would have before casting your >>vote. You will now be responsible for manually updating dependencies as new >>versions are released. You won't simply be able to drop in new JARs and be >>off and running. This isn't as much of an issue for server-based development, >>where Tomcat (or some such) will automatically load JARs from your lib >>directory; in client-side deployment, you will be required to update your >>classpath in all of your build and deployment environments. >> >>Other things to consider: >> >>- As Todd mentioned, .NET does not include version numbers in DLL names; it >>uses the Global Assembly Cache (a sort of meta-directory for code) to >>partition versions >>- Maven employs a directory structure to partition versions >>- Mac OSX employs a directory structure to partition versions >>- Other Apache projects including Tomcat and Ant do not embed version numbers >>in their JAR file names, only the distribution artifacts >>- The JAR files will still contain the version information in the manifest >> >>G >> >>On Friday, March 27, 2009, at 11:07AM, "Christopher Brind" >><[email protected]> wrote: >>>+1 >>> >>>2009/3/27 Todd Volkert <[email protected]> >>> >>>> There is some disagreement among the PPMC members as to whether we >>>> should include version numbers in our JAR files that we release, so >>>> I'd like to call for a consensus vote: >>>> >>>> Please cast your vote: >>>> [+1] include version numbers >>>> [=0] don't care >>>> [-1] don't include version numbers >>>> >>>> For some background, here are some links that discuss this issue: >>>> >>>> http://stackoverflow.com/questions/119426/jar-file-naming-conventions >>>> - advocates embedding the version number >>>> >>>> >>>> http://javahowto.blogspot.com/2006/05/java-jar-file-naming-conventions-and.html >>>> - advocates embedding the version number unless the JAR is distributed >>>> in a larger deliverable >>>> >>>> http://publib.boulder.ibm.com/wasce/V2.1.0/en/adding-java-libraries.html >>>> - advocates using a directory structure to partition JARs >>>> >>>> ** note that .NET does not embed version numbers in the file name. >>>> >>>> Thanks! >>>> -T >>>> >>> >> >> >
