All Apps and Add-ons

version vs. build settings in app.conf

Justin_Grant
Contributor

I’m seeing conflicting info in the Splunk docs about how an app should specify its version in app.conf.

I’ve seen 2 references:

How does the product use each of these? When an app is updated, should we update both of these?

1 Solution

Justin_Grant
Contributor

I dug through the Splunk Web and Splunk Manager code, and here's what I found:

Apparently build and version are totally unrelated to each other, but (arrrgh!) both must be incremented every time you rev your app. Here's more details:

"version" is displayed to the user in Manager, and on Splunkbase. Upcoming changes to Splunkbase will require that the version specfied in the UI when uploading into Splunkbase match the version specified in app.conf. Furthermore, when uploading a new Splunkbase version, the version string must be different from previous versions. These requirements together mean that you need to rev version in app.conf every time you upload a new version to Splunkbase. But, as far as I can tell, version isn't used anywhere else inside the Splunk product-- it's purely for display purposes inside the product.

"build", however, is used inside the product when generating URLs for static resources (images, CSS, etc.) Since your app's static resources are cached, updating the build number ensures that your new app's static files are reloaded at least once by the browser before being cached (until the next increment of the build setting).

So you'll definitely want to increment the build number every time you rev any of your app's static files.

And you'll want to increment version every time you upload a new version of your app to Splunkbase.

The safest thing would be to get in the habit of incrementing both every time you rev your app.

View solution in original post

southeringtonp
Motivator

And since you're going to want to update these every time you repackage your app, it ends up being easier just wrap the whole thing in a shell script that does the work for you, e.g.:

#!/bin/sh
#################################################
# Skeleton of app release script
#################################################
APPDIR=/opt/splunk/etc/apps/myapp

# Bump version number
cd $APPDIR
let VER=`cat .dist_version`
let VER=VER+1
echo $VER > .dist_version
perl -i -pe "s/^build\s*=.*/build=$VER/g" default/app.conf
perl -i -pe "s/^version\s*=.*/version=1.1.$VER/g" default/app.conf

# More stuff here (scrub private data, etc.)

# Build the archive
cd $APPDIR/..
tar cvzf myapp-$VER.tgz $APPDIR --exclude $APPDIR/local --exclude $APPDIR/metadata/local.meta

Justin_Grant
Contributor

Yep. Having a build script like this is definitely a smart best practice. We're going to see if we can generalize this idea somewhat (e.g. work on Windows and *nix, which probably means writing the build script in Python) but the general approach is the right one.

0 Karma

southeringtonp
Motivator

Note that this actually has the version kept in a THIRD location, a file called '.dist_version', but you could just as easily read it back from app.conf itself.

0 Karma

Justin_Grant
Contributor

I dug through the Splunk Web and Splunk Manager code, and here's what I found:

Apparently build and version are totally unrelated to each other, but (arrrgh!) both must be incremented every time you rev your app. Here's more details:

"version" is displayed to the user in Manager, and on Splunkbase. Upcoming changes to Splunkbase will require that the version specfied in the UI when uploading into Splunkbase match the version specified in app.conf. Furthermore, when uploading a new Splunkbase version, the version string must be different from previous versions. These requirements together mean that you need to rev version in app.conf every time you upload a new version to Splunkbase. But, as far as I can tell, version isn't used anywhere else inside the Splunk product-- it's purely for display purposes inside the product.

"build", however, is used inside the product when generating URLs for static resources (images, CSS, etc.) Since your app's static resources are cached, updating the build number ensures that your new app's static files are reloaded at least once by the browser before being cached (until the next increment of the build setting).

So you'll definitely want to increment the build number every time you rev any of your app's static files.

And you'll want to increment version every time you upload a new version of your app to Splunkbase.

The safest thing would be to get in the habit of incrementing both every time you rev your app.

Simeon
Splunk Employee
Splunk Employee

I recall using these values simply to track what version of an app I have built. I have not seen it used otherwise.

0 Karma

ftk
Motivator

I was wondering the same thing a couple of days back...

0 Karma

Justin_Grant
Contributor

FWIW, it seems like one of these settings is unnecessary. Build numbers are typically included along with version strings in most products.

0 Karma

jrodman
Splunk Employee
Splunk Employee

Note that just having the stuff in there as a string is of some use. However, it would be more useful if the admin could see it in manager.

0 Karma

sideview
SplunkTrust
SplunkTrust

Im very interested in this too. I looked into it a while ago and it looked like the product paid no attention to any of it.

0 Karma
Get Updates on the Splunk Community!

What’s New in Splunk App for PCI Compliance 5.3.1?

The Splunk App for PCI Compliance allows customers to extend the power of their existing Splunk solution with ...

Extending Observability Content to Splunk Cloud

Register to join us !   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to ...

What's new in Splunk Cloud Platform 9.1.2312?

Hi Splunky people! We are excited to share the newest updates in Splunk Cloud Platform 9.1.2312! Analysts can ...