Archive
Highlighted

version vs. build settings in app.conf

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?

Highlighted

Re: version vs. build settings in app.conf

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
Highlighted

Re: version vs. build settings in app.conf

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
Highlighted

Re: version vs. build settings in app.conf

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
Highlighted

Re: version vs. build settings in app.conf

Motivator

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

0 Karma
Highlighted

Re: version vs. build settings in app.conf

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
Highlighted

Re: version vs. build settings in app.conf

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

Highlighted

Re: version vs. build settings in app.conf

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
Highlighted

Re: version vs. build settings in app.conf

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
Highlighted

Re: version vs. build settings in app.conf

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