While the plugin has provision for enumerating tags and versions, there isn't a mechanism to specify which version is to be consider the 'latest' version, for the purpose of using the example HTML template to provide a message/alert to an update.
This setting appears to exist and hardwired to a poor default.
In many project the latest is considered to be the most recent stable release. This usually isn't master, that maybe considered a development branch. You project policy may vary.
== Nice to have feature request:
So this seems like it could do with being more configurable, documented and maybe even allow a lamdba function, to be an attribute decorator to be able to produce custom map key/value from being given a copy of the --dump-metadata for itself.
This way we can create our own is_version_some_state and no rely.
The default policies that exist for is_released and is_development_version can be recreated into that framework as a set of default lambdas executed.
This way any kind of policy can be implemented and feature/documentation requests like this to manage hardcoded stuff won't be needed.
While the plugin has provision for enumerating tags and versions, there isn't a mechanism to specify which version is to be consider the 'latest' version, for the purpose of using the example HTML template to provide a message/alert to an update.
https://github.com/Holzhaus/sphinx-multiversion/blob/master/sphinx_multiversion/sphinx.py#L199
This setting appears to exist and hardwired to a poor default. In many project the latest is considered to be the most recent stable release. This usually isn't master, that maybe considered a development branch. You project policy may vary.
== Nice to have feature request:
So this seems like it could do with being more configurable, documented and maybe even allow a lamdba function, to be an attribute decorator to be able to produce custom map key/value from being given a copy of the --dump-metadata for itself.
This way we can create our own is_version_some_state and no rely.
The default policies that exist for is_released and is_development_version can be recreated into that framework as a set of default lambdas executed.
This way any kind of policy can be implemented and feature/documentation requests like this to manage hardcoded stuff won't be needed.