Use changelogs/release.yaml for the version number source everywhere

[anoadragon453]

Currently both the top banner of the site and the top paragraph on the Changelogs page pull the current version number of the spec from config.toml, i.e:

https://github.com/matrix-org/matrix-doc/blob/6c6aa0b3d6eb6edc65c68ad78072a6733998969b/layouts/shortcodes/changelog/changelog-description.html#L8-L15

Note the {{ .Site.Params.version.number }} bit.

However, we already have a method of specifying the version number of a release build of the spec: changelogs/release.yaml:

https://github.com/matrix-org/matrix-doc/blob/6c6aa0b3d6eb6edc65c68ad78072a6733998969b/layouts/shortcodes/changelog/changelog-changes.html#L1-L16

This commit changes the site banner and Changelogs page to use tag in changelogs/release.yaml for the version number of the spec, instead of having two different ways to do things. Note that if we're building an unstable version of the spec, then changelogs/release.yaml is never read from.

[richvdh]

I'm not really familiar with this templating system, whatever it is - but it looks plausible, as long as you've tested it :)

[richvdh]

The thought occurs to me: if the unstable flag comes from config.toml, shouldn't the version number? In other words, should we go the other way and make changelog-changes use the value from config.toml rather than release.yaml?

Or should we move the unstable flag into release.yaml?

In short, why the inconsistency?

[anoadragon453]

I'm not really familiar with this templating system, whatever it is - but it looks plausible, as long as you've tested it :)

Oh right - I should've mentioned. It's hugo's own templating system. Looks quite similar to jinja2. https://gohugo.io/templates/introduction/

The thought occurs to me: if the unstable flag comes from config.toml, shouldn't the version number? In other words, should we go the other way and make changelog-changes use the value from config.toml rather than release.yaml?

The historical context is in #2992 (note that we switched from individual release.yaml files to a single one in #2992 after the global version number proposal). I believe the original reason for keeping it in a file versus config.toml was that we originally had to deal with multiple versions of the spec. Nowadays that's not the case.

It would certainly be easier in templates to pull a parameter from the config than parsing yaml files everywhere, so perhaps we should move the date and time into config.yaml. Note that the Changelog page only shows the current release version and the changes since the last release. We just export a different release per git tag, so there'll never be a need for multiple release.yaml files.

[anoadragon453]

@richvdh I've updated things to use the information in config.toml everywhere instead of having a separate changelogs/release.yaml file. Looks good on a test! 🙂

[richvdh]

lgtm otherwise. Presumably this necessitates a change to #3295?

[anoadragon453]

Presumably this necessitates a change to #3295?

Yep! Hope you don't mind if I do so via a rebase...