You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: