You’re right, I need to explain more precisely the most common use cases here. In Tutor, tags are needed to get reproducible builds of the Docker images. I need to know that all users are running the same versions of edx-platform, ecommerce, etc. in order to reliably reproduce issues when they face them. And if the Dockerfile includes a clone of a branch, instead of a tag, then the version that they will be running will be the one that exists when they built the Docker image. Also, building the Docker image could break from one day to the next without a change in the Tutor repo, resulting in flaky builds.
However, I also need to make sure that users are running an Open edX platform that includes all the security patches. Hence the various git patch calls.
Imagine I am downloading an XBlock or a new MFE developed by a 3rd party (not part of the core release). How would I know if it is compatible with my Open edX release?
Regarding security patches, I should have a means to identify if my installation is up to date or not. @regis’s issues with Tutor shows that whenever anyone wants to integrate the platform with another system, it is mandatory to have a deterministic control of software to check for dependencies and compatibility.
Also, Open edX is not only edx-platform. There are plenty of repos with components that should have a uniform version schema and cross compatibility check. https://semver.org has a proposal for version numbering, with the idea of major-minor-patch releases.