Proposal: As a developer I want truss to be semantically versioned so I can version lock.

[matthewhartstonge]

Hi TuneLab team!

First of all, thank you for truss!!! It's going to save us many hours of manual toil 👍👍👍 In the lead up to generating dependency management (as mentioned via MatthewHartstonge/truss#3) I was wondering if it would be possible to start versioning truss itself semantically to hold true to the paradigm being laid out with go dep which will be merged at some point into the standard go toolset.

I've started a PR that begins the journey into 'go dep~ism' but started with a focus on glide (what we have been using internally for all our go projects) but will change it over to go dep tomorrow, then begin the descent into truss'ing go dep dependency config file generation.

I would like to propose starting tagging at pre-release v0.1.0 until it's potentially stable (as per the readme) for 2 reasons: a) being semantically go dep~able b) ease of takeup via github releases with pre-built binaries c) SHA hashes make me 😭 😂

[adamryman]

I do like this. Though I would want both a version and a sha. A sha for when truss has little changes that are not breaking, rather than bumping the version on every commit. Then the version for breaking changes.