Various settings, in pom.xml files and other places, specify the version number for a Metron build and its sub-components.  When it is time to change the build version number, this article provides the steps to do so.

For the sake of example, we will assume the current version number is "0.4.0", and the desired new version number is "0.4.1".  All of the actions below are assumed to take place in a local git clone of the Metron source tree.  Generally speaking, version changes should be submitted in a PR just like any other source code change.

1. Determine the current version

The easiest way to determine the current version is to look in the root pom.xml file, at the top level of the xml, near the line that says 

    <artifactId>Metron</artifactId>

it will say:

    <version>0.4.0</version>

Other places the version number shows up are in the filenames of .jar and .rpm artifacts, and in the path of your local .m2 repository (if you've done a 'mvn install' build).

2. Change the Maven version

From the root of the local repo, first do

mvn clean

This will give you a lot less noise to deal with.  Then set the version using Maven 'versions' plugin:

mvn versions:set -DnewVersion=0.4.1

After reviewing the results, delete all *.versionsBackup files created.

3. Manually change the other version instances

Now grep for other instances of the old version number, excluding the website and generated docs areas.  Don't forget to backslash the "." (period) characters in the match string.  And you already did a 'mvn clean' in the previous step, right?

OLDVER='0\.4\.0'

for f in `grep -l -r --exclude 'site/*' --exclude dependency-reduced-pom.xml \
--exclude 'site-book/src/site/markdown/*' $OLDVER *` ; do 
echo " "; echo $f; grep $OLDVER $f; done

Audit the results in an editor, and fix all instances of the old version number that relate to Metron or its components, including:

  • site-book/pom.xml 
  • the mpack version number
  • other files as needed

Remember there may be instances of "0.4.0" that relate to dependency libraries, or are in explanatory text that may not need changing.  (Indeed, you can mess things up pretty badly by changing versions of dependencies!)  Also, you can ignore:

  • "dependency-reduced-pom.xml" files, and any other files you are sure are generated by build actions
  • metron-deployment/packaging/docker/rpm-docker/SPECS/metron.spec, which has historical references to old version numbers in the change log
  • Upgrading.md, which documents old version behavior

4. Verify the version changes

Do 'git diff' and examine the results to make sure you are happy with the changes.

Do a 'mvn clean install' with unit tests and integration tests, to make sure you did not induce any inconsistencies.

Consider soliciting additions to the Upgrading.md document if appropriate.

5. Submit a PR for the changes

Create and submit a Pull Request in the usual way for the version change patch.

When it's committed, you're done!