> -----Original Message-----
> From: Jason van Zyl [mailto:[EMAIL PROTECTED]]
> project.jar
> project-Major.Minor.jar
> project-Major.Minor.Patch.jar
Just an additional note. (I agree w/ what Vincent said, versioning in name
is bad)
IMHO a build number and/or a date is also missing.
If you look at the current state in cvs, project increment this based on
developers.
For example you can have loads of xalan-2.2d9.jar or velocity-1.2-dev.jar
that are ALL different with NO way to differentiate them. While we
obviouslly expect major and minor to be incremented by hand, this is not the
case for a build number that can be incremented automatically. (since it
might be impractical in some situations, a date could do the job).
All this clutters the name of the jar. So why not to a common jakarta
manifest that will contain things such as:
version.major: <digit>
version.minor: <digit>
version.quality: (development|alpha|beta|release-candidate|release)
version.date: <yyyy.MM.dd hh:mm:ss z>
version.debug: (true|false)
as well as the name of the project of course.
One thing that I may agree is the naming for a debug version that can be
postfixed by 'd' but this is really secondary since nearly everything is
built and shipped in debug.
I think a common manifest it will greatly help to quickly identify binaries
for end-users AND developers. it is painful to have all sort of binaries
with version that are burned into the code.
org.apache.xalan.xsl.EnvironmentCheck is a first step to identify xerces,
xalan and potentially jaxp and crimson that can save you some time by not
decompiling a jar.
Sometimes the version is simply not available.
Comments ?
Stephane
