Hi Henrik,
In most instances, version numbers aren't part of filenames. Consider
executables. For example, OS commands such as 'ls' aren't ls-1.1.
Scripts are written to depend on resources with constant naming. The
same applies to jar files. Code can be written to use standardized
filenames and can be depended upon to work even when jar files are
updated. In Linux, the /alternatives /command is one way of managing
versioning. And, there are plenty of other approaches to versioning.
For jars, the manifest.mf is a common (and standard) place to set
package version information
<https://docs.oracle.com/javase/tutorial/deployment/jar/packageman.html>.
In modern deployment environments such as cloud computing, in
particular, the notion of version is not as relevant as it used to be.
Customers do not think of what version software is in the cloud. It is
the application that is undergoing continuous, agile, modification.
Having version numbers as part of filenames breaks the use of these
files as reusable components. The issue of binary, source code, and
behavioral compatibility is important. As long as contracts are
preserved, all is well. In any event, a version number is a very weak
indicator and cannot be relied on to determine compatibility. Thorough
testing before deploying code that relies on updated jar files is important.
And, from a security perspective, we're looking at standardized
filenames and testing them against various exploits. It is better to
have a relatively unchanging set of names that we can run checks against
to determine what they are by checksums, etc. Security is becoming a
bigger and bigger concern, and efforts should be made to have consistent
filenames across releases so that changes are more readily identifiable.
From at IT perspective, changes are pushed out to developers to ensure
that they're developing into standardized environments. We're
essentially doing at least the following as a workaround:
VERSION=2.4.4
cd /usr/local
rm -rf groovy-$VERSIONgroovy
unzip -q /network/path/to/apache-groovy-sdk-$VERSION.zip
ln -s groovy-$VERSION groovy
cd groovy-$VERSION
find . -name "*-$VERSION*" | while read FILENAME ; do
STANDARD_NAME=$(echo "$FILENAME" | sed "s/-$VERSION//")
mv $FILENAME $STANDARD_NAME
done
Note that the above isn't perfect as the internal components of the zip
archive include other jar files with version numbers other than the
Groovy version number. One could remove version numbers from all
files. It's merely used for illustration and shouldn't be used in any
production environment.
Apache's own HTTP <http://httpd.apache.org/download.cgi> or Tomcat
<http://tomcat.apache.org/download-80.cgi> code that doesn't use
filenames with embedded version numbers; however, counter examples
include Hadoop <https://hadoop.apache.org/releases.html> and Lucene
<https://lucene.apache.org/core/> that do use version numbering in
filenames. So, it is clear that this is an area that has not been
standardized with the ASF. Perhaps the Apache folks can chime in on this.
We continue to assert that having version numbers, or other metadata, as
a part of filenames is a bad practice. We do have workarounds in place,
but think it would benefit the community to consider this change.
Enjoy,
Steve Amerige
Principal Software Developer, Fraud and Compliance Solutions Development
SAS Institute, 100 SAS Campus Dr, Room U3050, Cary, NC 27513-8617
On 7/28/2015 10:38 AM, Henrik Martin wrote:
I'm not part of the contributor team, so I can't speak for the Groovy
team, but I would strongly disagree with you. If you use Maven or
Gradle, it's easy to maintain dependencies on particular versions of
jar files, and have your IDE immediately pick up the new version. In
fact, the default behavior for both Maven and Gradle is to explicitly
maintain version numbers in artifacts. Removing this would be a step
back to the 90s. Sometimes jar files have to copied into other
directories outside of their normal home. An example is when deploying
Tomcat. Stuff like jdbc drivers etc typically get copied into
$CATALINA_BASE/lib. It's worth gold to immediately be able to tell
which particular version of those jar files are in there, vs just
seeing "foobar.jar".
I would argue that you should probably change the practice of creating
symlinks to explicitly versioned jar files as this is obviously a pain
when new versions are introduced.
Just my $0.02.
-H
On 7/28/15 5:26 AM, Steve Amerige wrote:
Hi all,
Every time we take a download of the latest Groovy software, we have
to do the same task: remove version numbers from filenames. As of
the 2.4.4 release, there are 39 files, shown below, that have the
version number as part of the distribution. So, why is this a problem?
* IDEs cannot silently be updated to use a mandated Groovy
version. With 2.4.4 dealing with a zero-day vulnerability issue,
we want to push this out. However, the version numbers in files
mean that users must participate in the updating. This is not
desirable.
* Links that users might have at the OS level are broken with each
new release.
* Version numbers in files makes it more difficult to diff between
releases.
* Version numbers as a part of a filename is a specific case of
metadata as part of filenames and, as such, we consider it to be
a bad practice. This information is better kept in a file,
preferably machine readable in a format such as JSON or XML, or
in manifest files that can be consumed by software that might do
version number validation as part of security efforts in
maintaining code.
It is reasonable that the root directory include a version number.
But, under that directory, we'd expect that the contents are
version-less. A good example of a version-less Apache project is the
HTTP Server <http://httpd.apache.org/download.cgi>. The download is
presently a file named *httpd-2.4.16.tar.gz*, and when extracted
produces a top-level directory named *httpd-2.4.16*. No file name
contains the version number string. The two files *CHANGES *and
*httpd.spec *contain the version number string. I believe that
Groovy should follow this example, and possibly go one step better by
having an explicit manifest file with all pertinent metadata for the
Groovy release that includes metadata such as the version number,
license name, checksums of files (for security checking), etc.
If you agree, how can we start the process of making this change?
Thanks,
Steve Amerige
Principal Software Developer, Fraud and Compliance Solutions Development
SAS Institute, 100 SAS Campus Dr, Room U3050, Cary, NC 27513-8617
./lib/groovy-sql-2.4.4.jar
./lib/groovy-testng-2.4.4.jar
./lib/groovy-jsr223-2.4.4.jar
./lib/groovy-servlet-2.4.4.jar
./lib/groovy-json-2.4.4.jar
./lib/groovy-jmx-2.4.4.jar
./lib/groovy-test-2.4.4.jar
./lib/groovy-bsf-2.4.4.jar
./lib/groovy-groovydoc-2.4.4.jar
./lib/groovy-nio-2.4.4.jar
./lib/groovy-console-2.4.4.jar
./lib/groovy-xml-2.4.4.jar
./lib/groovy-ant-2.4.4.jar
./lib/groovy-docgenerator-2.4.4.jar
./lib/groovy-groovysh-2.4.4.jar
./lib/groovy-templates-2.4.4.jar
./lib/groovy-swing-2.4.4.jar
./lib/groovy-2.4.4.jar
./apache-groovy-src-2.4.4-incubating.zip
./embeddable/groovy-all-2.4.4-indy.jar
./embeddable/groovy-all-2.4.4.jar
./indy/groovy-json-2.4.4-indy.jar
./indy/groovy-console-2.4.4-indy.jar
./indy/groovy-2.4.4-indy.jar
./indy/groovy-sql-2.4.4-indy.jar
./indy/groovy-jmx-2.4.4-indy.jar
./indy/groovy-servlet-2.4.4-indy.jar
./indy/groovy-xml-2.4.4-indy.jar
./indy/groovy-swing-2.4.4-indy.jar
./indy/groovy-templates-2.4.4-indy.jar
./indy/groovy-ant-2.4.4-indy.jar
./indy/groovy-groovydoc-2.4.4-indy.jar
./indy/groovy-nio-2.4.4-indy.jar
./indy/groovy-test-2.4.4-indy.jar
./indy/groovy-testng-2.4.4-indy.jar
./indy/groovy-groovysh-2.4.4-indy.jar
./indy/groovy-docgenerator-2.4.4-indy.jar
./indy/groovy-bsf-2.4.4-indy.jar
./indy/groovy-jsr223-2.4.4-indy.jar
