Let me report here what I said yesterday during the BTR meetup (sorry again for not noticing this topic earlier).
On the one hand, tags are useful to me, as a maintainer of Tutor, to obtain reproducible Docker builds. Patches (bug and security fixes) are applied one by one in the edx-platform, ecommerce, etc. images: https://github.com/overhangio/tutor/blob/718a6a5cf9aa433756ae00c6d31ac4033cc8c606/tutor/templates/build/openedx/Dockerfile#L36
...
RUN curl https://github.com/edx/edx-platform/commit/<git sha1>.patch | git apply -
...
On the other hand, I agree that tags are inconvenient, as they can quickly become obsolete.
So I’d like to propose a mixed approach. Since we agreed upon a 6-month release frequency, maybe we could also switch to periodical minor tags? It would work like this:
- On the day of the release (D+0), create the open-release/xxx.1 tag.
- At D+2 months, tag open-release/xxx.2
- At D+4 months, tag open-release/xxx.3
Minor tags would thus give us an indication of how close we are to the next major release. Also, if we need to tag open-release/xxx.4, then that’s a clear indication that we are behind on schedule for the next release.
What do you think?