feat: expose integer Tutor version parts to templates

[kdmccormick]

WIP

@michaelwheeler

[michaelwheeler]

For some context, this is related to a question that I brought up during the Tutor Users' Group about writing plugins that support multiple Tutor versions. We're currently doing something along the lines of...

{% if TUTOR_VERSION.startswith("14.") %}
# Do something for Tutor v14 only...
{% else %}
# Do something for Tutor versions after 14...
{% endif %}

But having major/minor/patch versions available to the context as integers would allow more precision and flexibility.

[regisb]

@michaelwheeler I'd like to understand better your use case. Have you considered having multiple branches for your plugin, one for every major release?

[michaelwheeler]

Have you considered having multiple branches for your plugin, one for every major release?

In our team, managing multiple branches for our plugins felt like more overhead than adding an occasional conditional. We also think it will slightly simplify the process of upgrading to a newer named release.

[arbrandes]

I think this would useful to have as an option for plugin authors, particularly for cases where the plugins don't change that much between releases.

[regisb]

Right. I'm still not sure if it makes sense to add these settings to Tutor core. You do know that you could define these variables in your own plugin by adding a callback to the ENV_TEMPLATE_VARIABLES filter, right?

[michaelwheeler]

You do know that you could define these variables in your own plugin by adding a callback to the ENV_TEMPLATE_VARIABLES filter, right?

I didn't know that!

It still feels to me like Tutor should provide the variable, since the version is a property of Tutor itself, but if that's undesirable for other reasons then maybe ENV_TEMPLATE_VARIABLES can get me where I need to go.