Make `spin --version` more obvious at unreleased commits

[lann]

For example, with recent checkout of Spin spin --version gives: spin 0.4.0 (7404232 2022-07-15) . For someone not already familiar with this it isn't obvious that this includes code committed after the 0.4.0 release.

[radu-matei]

I agree. I've also seen the convention to append -dirty (or perhaps something a bit more pleasant-sounding) if there are local changes that have not been committed, which I liked because it made it even more obvious that you have local changes.

[lann]

This comment on the semver repo suggests bumping the patch version immediately after a release and adding a prerelease tag, e.g. 0.4.1-beta.0. As noted in the comments, its a little annoying that version 0.4.1 may never actually be released, but maybe it's still the least-bad option.

[lann]

I guess you could also then bump the minor version as soon as you have incompatible changes - bumping the version to 0.4.0-something with the wasmtime upgrade would have made sense.

[waveywaves]

/assign

[waveywaves]

Would appending -devsuffice ? Having the commit id in there would be nice as well I guess :thinking:

[lann]

Maybe. I think the main point is that it's odd for the version to include 0.4 after 0.4 is released. It may be that we actually need to update our release process

[waveywaves]

Then it makes sense to add the minor / patch version in the mix for the version. So the dev should show something like 0.4.1-dev-${commit_id} or 0.5-dev-${commit_id}. You are right, a change in the build process would be good to recognize this and the --version flag to then reflect it.