Cht-core: Make sure app versions are always in sync

[garethbowen]

Describe the issue
We display app versions in two places with two different sources

1. The logo tooltip is set using an Angular constant which is set when Grunt builds the app by pulling it out of the package.json.
2. In the About page which pulls it from the deploy_info on the local medic-client ddoc. This only exists for tagged releases and falls back to the package.json version for development builds, alpha releases, etc.

Updating the package.json is a documented step of the release process but it's easy to miss, which leads to last minute bugs.

Describe the improvement you'd like
I can see two possible solutions...

1. Add a test or build time check which fails the build when a tag is created that doesn't match the package.json version, but that'll fail late in the process.
2. Set the package.json version to 1.0.0 permanently and show "unknown" for the version for non-tagged releases. This cleans up the code a little, removes a step from release management, and means the version will always be correct (unless unknown).

Describe alternatives you've considered
Nagging people constantly...

[garethbowen]

I'm leaning towards solution 2 here. I think displaying the package.json version is misleading anyway because it'll report 3.8.0 for dev environments which may have any sort of local changes.

@SCdF What do you think?

[SCdF]

I think we use the version in the package.json to do other things as well, like determine the "base" version in horti, which is used to determine potential compatibility when deploying random branches and things.

Updating the package.json is a documented step of the release process but it's easy to miss, which leads to last minute bugs.

This isn't one of your solutions, but do you think we could script this to avoid missing a manual step? So it would tie together creating a tag in the right format, updating the package.json and package-lock.json, and anything else that we can put in there.

[garethbowen]

So it would tie together creating a tag in the right format, updating the package.json and package-lock.json, and anything else that we can put in there.

All these things are done at different times. When 3.7.x branch is created, master package.json should be updated to 3.8.0 (this hasn't happened yet which is another case of it being too easy to miss in the documentation). It's easy to write a script to update the package.json and package-lock.json (in fact npm version minor will do this automatically) but that's all that it'll do.

I thought about writing a test that finds the latest tag in GH and makes sure the package.json version is semver greater than that. This would mean it fails early and in master but it's fairly complicated to write.

I think we use the version in the package.json to do other things as well, like determine the "base" version in horti, which is used to determine potential compatibility when deploying random branches and things.

Ahh I see it in the Gruntfile now... rats! I'll go back to the drawing board.

[garethbowen]

This is an ongoing problem affecting 3.6.1, 3.7.0, and now 3.8.0 so we need to change something. I'll try to make it clear to release managers that they need to do the "Development" section as soon as they are nominated to run the release.

I'd also like to...

1. Remove the app version from the logo tooltip as a more complete version number is available on the About page. The alternative is to use the same version in the tooltip too but that requires looking up the ddoc and extracting some information and I don't want to slow down the initial load, particularly as it's hidden from mobile users anyway. @abbyad Are you ok with this change?
2. Add a test that only runs when travis is building a tag in release format (eg: "3.6.1") and ensures that it matches the package.json version. This will fail annoyingly late and will require deleting and recreating the tag after correcting the version but it will guarantee the "base version" is correct. Hopefully with better docs and manual processes we'll catch it before it gets this far. @SCdF How does that sound?

[SCdF]

@garethbowen the test seems like a good option :+1:

[abbyad]

Yes Gareth, having the version in the About page replaces the need for it in the tooltip. I don't think we had that info elsewhere in the app when the tooltip was introduced.

[garethbowen]

Ready for AT in 6054-make-versions-consistent

[newtewt]

@garethbowen The webapp portion of this works fine. I think there is likely some work still though to be done. I'm seeing an error when I build it. The job also didn't fail when that errored too.

I forked the repo
checked out your branch in my local repo
git tag 3.8.0 the package.json is 3.7.0
git push --tags
The build is triggered under my travis account. I see the error below.

```Running "exec:check-version" (exec) task

/bin/sh: 1: [[: not found
Running "exec:undo-patches" (exec) task```

[garethbowen]

Great find - sorry about that!

I've updated the PR - can you please try again?

[newtewt]

All looks good now. Failing when it doesn't match and passing when it does.