We should add library version info to the JSS shared library. Although we put the major version number in the library name (for example, libjss3.so), one can't tell whether it is JSS 3.0, 3.1, or 3.1.1. You can do what we did with NSPR and NSS. 1. On Unix, we add sccs and rcs version identification strings that can be extracted with the 'what' or 'ident' command. For example: % what libnss3.so | grep NSS NSS 3.3 Beta (debug) Jun 25 2001 21:12:56 % ident libnspr4.so libnspr4.so: $Header: NSPR 4.1.2 (debug) Thu Jun 21 15:21:32 PDT 2001 $ 2. On Windows, we link in the DLL a version info resource. You can use Windows Explorer to open the file, choose the "Properties" menu item, and look at "Version". Use the following files for libnss3.so/nss3.dll as an example. 1. mozilla/security/nss/lib/nss/nss.h: this defines the macros NSS_VERSION, NSS_VMAJOR, NSS_VMINOR, NSS_VPATH, and NSS_BETA. It also declares a C function NSS_VersionCheck(), which may not be applicable to JSS. 2. mozilla/security/nss/lib/nss/nss.rc: this is the Windows version info resource file. 3. mozilla/security/nss/lib/nss/config.mk: this defines RES and RESNAME to cause coreconf to compile the .rc file and link it into the DLL on Windows. 4. mozilla/security/nss/lib/nss/nssver.c: this defines the sccs and rcs version identification strings that can be extracted by 'what' and 'ident'. 5. mozilla/security/nss/lib/nss/nssinit.c: must be a different file from nssver.c. This contains a reference to the version identification strings in nssver.c to prevent the compiler from optimizing them away. (The AIX compiler would do that.) We should get this done before JSS 3.1 RTM.
Added version information as Wan-Teh suggested. I'm going to look into the best way to do this to the class file. We used to have something similar in JSS 2.1 /cvsroot/mozilla/security/jss/lib/config.mk,v <-- config.mk new revision: 1.15; previous revision: 1.14 /cvsroot/mozilla/security/jss/lib/jss.rc,v <-- jss.rc initial revision: 1.1 /cvsroot/mozilla/security/jss/org/mozilla/jss/util/jssutil.c,v <-- jssutil.c new revision: 1.5; previous revision: 1.4 /cvsroot/mozilla/security/jss/org/mozilla/jss/util/jssver.c,v <-- jssver.c initial revision: 1.1 /cvsroot/mozilla/security/jss/org/mozilla/jss/util/jssver.h,v <-- jssver.h initial revision: 1.1 /cvsroot/mozilla/security/jss/org/mozilla/jss/util/manifest.mn,v <-- manifest.mn new revision: 1.5; previous revision: 1.4
Since the the classes live in a JAR file, which may be compressed, we cannot merely embed an ident string in the class. But, the ZIP file format does allow for comments, which are not compressed. They are added with "zip -c <zipfile> <comment>". We can use this command to label the class files after they are built. This should be added to Anthony's release script.
To clarify my last post, I propose we add an ident string as a comment, so the user can simply run "ident" on the jar file. The command to do the labeling would look like this: echo '$Id: JSS Version 3.1 BETA $' | zip -z jss3.jar Unfortunately the zip program reads the comment from stdin, not a command-line argument.
That sounds good to me, but do jar files have their own versioning method?
Sun do have a standard versioning method of embedding version information in the manifest: http://java.sun.com/products/jdk/1.2/docs/guide/versioning/spec/VersioningSpecification.html#PackageVersioning It would be pretty hard to put this in our current build system, and I don't think it really matters to our customers which mechanism we choose.
I confirmed that I could view the DLL version information on jss3.dll on Windows.
Jamie, thanks for the pointer to Java package versioning. It is too late to add this to JSS 3.1 but it seems like a good thing to do in the future. Your suggestion of adding an ident string as a comment is good. Please go ahead and add both sccs and rcs ident strings to JSS 3.1.
Updated from Beta to RC1. /cvsroot/mozilla/security/jss/org/mozilla/jss/util/jssver.h,v <-- jssver.h new revision: 18.104.22.168; previous revision: 1.1