Userguide: set and display current version, versioning

[deining]

Browsing the user guide sources, I just realized that the version parameter inside config.toml of the userguide is not set:

119 # The version number for the version of the docs represented in this doc set.
120 # Used in the "version-banner" partial to display a version number for the 
121 # current doc set.
122 version = "0.0"

Since we no do have our first version 0.1.0 in place, I suggest we set this version number when releasing future versions. I think a release checklist would be helpful, one item to be checked should be increment of the version number so that this is not forgotten. Not sure if we want to set x.x.x-dev for all commits between releases. Since we now do have a version number, I would like to see this version number printed in the headline of the docsy userguide. Not sure if we should/want to populate the dropdown with older versions of the userguide, allowing to look at older versions of the user guide. I don't think the current repo structure allows for this easily, but I may be wrong here.

[LisaFC]

So there are a few Docsy sites that keep old versions published, eg https://kubernetes.io/ - in that case they just keep a static snapshot of the site up rather than eg deploying it from a repo branch, and the archived docs are not maintained. I think we could do that if we wanted - thoughts? Though we're unlikely to have as many per-version changes as K8s, so I'm not sure how useful it is to have a complete set of docs for each version, versus just specifying "added/updated in [version number]" to the relevant sections.

The version number in the config is only used if you have a version banner for archived docs, it doesn't show up in the current/latest version - we'd need to add something to the header (as well as a config parameter for whether you want to display it).

[chalin]

I'd vote to post only the current version, and direct folks to other services for older docs like https://web.archive.org.

Adding version info, or even the id of the last commit to the footer is really useful IMHO.

[at055612]

Adding params.version and the commit to the footer would be really useful. The site wide commit date would also be useful in the footer, as distinct from the commit date on each page.