We source our modules from .git. and are used to seeing tags matching the forge release.
It's good practice - and gives you the ability to trace back bugs from modules into the code that causes it.
One way to help retroactively do this is run a git log metadata.json and you can see where each version changed in that file - assuming it was kept accurate.
Generally however, it would be at least sufficient moving forward to tag the current release and all subsequent ones.
Would you mind doing this? I'm pretty sure tags won't go through a Pull Request or I'd submit one.
Thanks for reporting this, we'll certainly tag releases from now onwards, and I've retrospectively added tags corresponding to previous Forge releases.
We source our modules from .git. and are used to seeing tags matching the forge release.
It's good practice - and gives you the ability to trace back bugs from modules into the code that causes it.
One way to help retroactively do this is run a
git log metadata.json
and you can see where each version changed in that file - assuming it was kept accurate.Generally however, it would be at least sufficient moving forward to tag the current release and all subsequent ones.
Would you mind doing this? I'm pretty sure tags won't go through a Pull Request or I'd submit one.