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
The footer of the template includes "Using The Carpentries style version 9.5.3." (it has been the same version number for a long time...)
The version number is hard-coded, and we continuously bring improvements to the template, which is not very suitable for a release-based versioning system.
I'm wondering if we could use a GitHub Actions workflow to insert into the footer the (short) sha1 from the latest commit (or something else) to identify the version number. This could possibly be done with a variable (stored in _config.yml or _data/version.yml for instance).
One of the drawbacks is that it would create a lot of noise in the commit history.
The text was updated successfully, but these errors were encountered:
I'm wondering if we could use a GitHub Actions workflow to insert into the footer the (short) sha1 from the latest commit (or something else) to identify the version number. This could possibly be done with a variable (stored in _config.yml or _data/version.yml for instance).
We can definitely do that for lessons and it shouldn't create too much noise -- one extra PR when lessons sync up with this repo. We can create an action that would submit a pull request to update _includes/lesson_footer.html.
The footer of the template includes "Using The Carpentries style version 9.5.3." (it has been the same version number for a long time...)
The version number is hard-coded, and we continuously bring improvements to the template, which is not very suitable for a release-based versioning system.
I'm wondering if we could use a GitHub Actions workflow to insert into the footer the (short) sha1 from the latest commit (or something else) to identify the version number. This could possibly be done with a variable (stored in _config.yml or
_data/version.yml
for instance).One of the drawbacks is that it would create a lot of noise in the commit history.
The text was updated successfully, but these errors were encountered: