>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3404082. --> Reported by: [cmlara](https://www.drupal.org/user/1790054) >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>Previously under DrupalCi the majority of image usage was controlled by the DA. To this design images were either Production or Dev images.</p> <p>With the migration to GitLab the Images have transitioned to a status where they are now a base for CI operations. The DA no longer directly controls all operations, maintainers are encouraged to extend/modify the CI process as needed to fit their project needs.</p> <p>The DrupalCI images are currently the foundational base of the gitlab_templates repository which is encouraged as the base for configuring GItLab based CI on G.D.O.</p> <p>This transition us to a state where the DrupalCi Environment images are now being used in a manner that depends upon reliably signaling changes and maintainers needing the tools to control adoption of those changes.</p> <p>As an example the work on <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/drupalci_environments/-/work_items/3387737" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/drupalci_environments/-/work_items/3387737</a></span> was promoted from the dev images to the tagged production images yesterday (Context: during a US holiday which for many continues until Monday). This change can/does break CI testing for some projects.</p> <p>Thankful my projects just end up not running Code Coverage and this created a soft fail, however if I had adopted Mutation testing (which depends upon code coverage) it would have been a hard fail.</p> <p>While I was aware this work was in-progress, and suspected I would need to eventually update my Gitab template files there was no advance warning that this change would occur yesterday and that I needed to update all my projects before the holiday.</p> <p>Addtionaly for point-in-time testing (needing to back and test older dev cycles) having reliably retrievable images would also help.</p> <p>The gitlab_templates project could handle most of the issues regarding when/how to upgrade to a new major and how to announce it, the images just need to be tagged in a way that allows the templates to do so.</p> <p>Naming like drupalci/apache-php-8.2:X.Y.Z (with a side label of drupalci/apache-php-8.2:latest pointing to the latest in the highest major and drupalci/apache-php-8.2:X pointing to the highest version in the specified major) would likely be sufficient for templates to refer to these images.</p> <p>How we want to sync the majors/minors would be the biggest question. </p> <p>I would suggest that at least the majors be synced in such a manner that one could use the major specific tag across all currently maintained CI images without expecting errors to occur due to tooling (in other words: the only errors we should expect would be related to the version of PHP and not the rest of the image.)</p> <h4 id="summary-steps-reproduce">Steps to reproduce</h4> <p>N/A</p> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>Adopt SEMVER type numbering for images being pushed to Docker Hub,<br> Any changes that could break existing installs (such as removing programs, removing libraries, disabeling modules, etc) be done as a major release.<br> Any changes adding new features (adding new modules, tools, upgrading versions of tools without changing their interface methods, etc) be done as a Minor release<br> Any changes that only fix faults in the existing images be done as a patch release. </p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <p>TBD</p> <h3 id="summary-ui-changes">User interface changes</h3> <p>None</p> <h3 id="summary-api-changes">API changes</h3> <p>Adds a definition of the images being considered API.</p> <h3 id="summary-data-model-changes">Data model changes</h3> <p>None</p> > Related issue: [Issue #3516958](https://www.drupal.org/node/3516958)