Hi,
I was wondering how other teams go about versioning their app and displaying the version on the active website. Any thoughts on putting the version number in settings.json versus putting it in package.json vs putting it in an environment variable? I’ve tried all the above, and they each have some pros/cons. We’re going live with some new systems and I need to choose one, and am trying to figure out if there’s a consensus on which of the different options is the best practice.
-aw
Here’s how I ended up doing it. I use git tags to track the version number.
On the server, before the project it built for production, my setup will run this script (at the root of the project). It creates a file in my private folder called “version.json”.
version.sh
#!/bin/sh
ver=$(git describe --abbrev=0)
complete=$(git describe)
branch=$(git rev-parse --abbrev-ref HEAD)
commit=$(git rev-parse HEAD)
timestamp=$(git log -1 --date=short --pretty=format:%cd)
cat > private/version.json << EOF
{
"basic": "$ver",
"complete": "$complete",
"branch": "$branch",
"commit": "$commit",
"timestamp": "$timestamp"
}
EOF
private/version.json
{
"basic": "1.4.3",
"complete": "1.4.3",
"branch": "staging",
"commit": "2fc51b04b845fd88d41ba94c5f9a87d69742c1c4",
"timestamp": "2018-03-08"
}
Then you can define a server only meteor method to read the file:
Meteor.methods({
'app.version'() {
try {
var version = {};
version = JSON.parse(Assets.getText("version.json"));
return version;
} catch(e) {
// .. Version not found
return {};
}
}
});
9 Likes
Ooooh, nice. That looks like a really great pattern. Might be exactly what I was looking for. Going to give it a try this week!
We don’t even have version numbers. When we deploy, our app sends the commit hash to our Slack deployment channel. That’s all we really need to know what was deployed in case of a rollback. How do users use the version number?
2 Likes
Our app has some similarities to Rocket Chat, in that we have a downloadable version that can be run as a desktop app or mobile app, as well as a hosted online version. Importantly, we have a plugin architecture and wordpress business model, where we offer the core build (aka interface engine/router) as a platform that users can build plugins and their workflow on. In the world of healthcare interoperability, this model will be a significant departure from how many of the incumbents currently do health IT development.
So…
a) we need to peg our version releases with version release of the FHIR protocol
b) users need release versions that they can peg their plugins to.
c) we’ll have various feature rollouts (i.e. ICD-10 support, SNOMED, etc)
That being said, I quite like the git commit based versioning and using git tags. I’m quite excited to be implementing it (doing it today), and think it may be what we’ve been missing. I like how we can still have semver tags and releases, which will be important for publishing packages, plugins, and coordinating with users.
1 Like
