>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #2681459. --> Reported by: [frankcarey](https://www.drupal.org/user/112063) >>> <h3>Problem/motivation</h3> <h4>User Story</h4> <blockquote><p>As a contrib developer,<br> I want to have the option to use semver release tags like 7.x-1.0.1 for my modules,<br> So that I can communicate to users the difference between releases that change features vs bugfix/security releases </p></blockquote> <h4>Why now?</h4> <p>The D.O Engineering team is currently working on getting a composer shim service in place. It makes sense to tackle this at the same time.</p> <h4>Background</h4> <p><span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/drupal/issues/1612910" title="Status: Closed (fixed)">#1612910: [policy, no patch] Switch to Semantic Versioning for Drupal contrib extensions (modules, themes, etc)</a></span> - There is a 300+ comment ticket as a policy proposal to do this in contrib. There have been many proposals debated and there seems to be some consensus around allowing a 7.x-1.0.1 format for contrib releases and because it should be the easiest option to enable on d.o -( per @drumm <a href="https://www.drupal.org/node/1612910?page=1#comment-10913926">comment</a> )</p> <h4>Usage examples</h4> <p><strong>I have a release that will only contain bugfixes</strong> - A bunch of bugs have been fixed, but there are no functional changes in the code. As a developer, I want to signify this fact by only incrementing the patch position in the semver version identifier.</p> <p><strong>I created an "oops" release</strong> - As a developer, I push a new 7.x-1.0 release of my module and then someone comes along letting me know that I made a small typo and my module is causing errors. I'd prefer to release a 7.x-1.0.1 to signify that this release was just to fix an small issue and doesn't include new features.</p> <p><strong>I fixed a security issue</strong> - As a developer, the security team find a security issue that needs to be resolved in my 7.x-1.0 release, but there are also new features in my 7.x-1.x branch that are not ready for release just yet. Instead of pushing all this code out at once, I can just create a new branch from 7.x-1.0, patch the security issue, and then release a 7.x-1.0.1 branch. (in addition to patching 7.x-1.x) so that users can upgrade with more confidence knowing that the only changes were minor / security patches.</p> <p><strong>I host a distribution / install profile on d.o </strong> - As a distro developer, I use drupal.org.make files and my distro is on release 7.x-1.4. Drupal or some set of the modules that my distro relies on have security releases before I'm ready to release a new version of my distro. I want to create a 7.x-1.4.1 release so that I can update just my make file for 7.x-1.4 to use the latest drupal and module security releases.</p> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <ul> <li>API-compatibility-prefixed releases will remain mostly same, <code>{api compatibility}-{major}.{minor/patch}</code>. We currently store the last position as &ldquo;patch&rdquo;, but treat it more like &ldquo;minor&rdquo; in places like the Composer fa&ccedil;ade.</li> <li>If you omit the API compatibility prefix, tagged releases will be semver <code>{major}.{minor}.{patch}</code>.</li> <li>Dev release branches may be <code>{major}.x</code> or <code>{major}.{minor}.x</code>. If a project intends to do releases linearly, the maintainer can omit maintaining a branch for each minor version.</li> </ul> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <p><strong>Ensure Drupal.org services support</strong></p> <p><span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/project_composer/-/issues/3104693" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/project_composer/-/issues/3104693</a></span><br> <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/l10n_server/issues/3091062" title="Status: Closed (fixed)">#3091062: Package translations for semantically-versioned contrib releases</a></span><br> <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/infrastructure/issues/3069715" title="Status: Closed (fixed)">#3069715: ftp.drupal.org has fallback regex's that need to account for semver.</a></span></p> <p><strong>&#10024;Enabling semantic versioning for all projects&#10024;</strong></p> <ul> <li>Semantic version releases for contrib should not available until Drupal fully supports this. All of the must have issue but first completed here <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/drupal/issues/3009338" title="Status: Closed (fixed)">#3009338: [META] Support semantic versioning for extensions (modules, themes, etc) in Drupal core, and allow modules to be compatible with Drupal 8 and 9 at the same time</a></span></li> <li>Final enabling for all projects will be <code>drush vset project_release_version_format_project_release '!api#major%minor%patch#extra'</code>, then clean up any projects that were used for testing, <code>SELECT * FROM field_data_field_release_version_format;</code> </li></ul> <p><strong>Documentation &amp; UI updates</strong></p> <p><span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/project_git_instructions/issues/2297975" title="Status: Closed (fixed)">#2297975: Update docs to support semantic versioning</a></span><br> <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/drupalorg/issues/3115728" title="Status: Closed (fixed)">#3115728: Project Documentation forms need to allow for semver.</a></span></p> <p><strong>Cleanup old data</strong></p> <p><span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/project_composer/-/issues/3114968" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/project_composer/-/issues/3114968</a></span><br> <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/project/issues/3104698" title="Status: Closed (fixed)">#3104698: Remove {project_release_supported_versions}.tid column</a></span><br> <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/drupalorg/issues/3104888" title="Status: Closed (fixed)">#3104888: Remove 9.x API compatibility term, if possible</a></span></p> <h3 id="summary-ui-changes">User interface changes</h3> <p>Should be done soon, not a blocker to enabling for all projects.</p> <p><span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/project/issues/3104886" title="Status: Closed (fixed)">#3104886: Update/remove API version filter on &ldquo;All releases&rdquo; pages</a></span><br> <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/project/issues/3089291" title="Status: Closed (fixed)">#3089291: Group issue version &ldquo;series&rdquo; by branch instead of API compatibility</a></span></p> <h3 id="summary-api-changes">API changes</h3> <p>Completed as part of <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/drupalorg/issues/2688479" title="Status: Closed (fixed)">#2688479: Update update status XML for Drupal 9 and contrib semantic versioning</a></span>, documented at <a href="https://www.drupal.org/drupalorg/docs/apis/update-status-xml">https://www.drupal.org/drupalorg/docs/apis/update-status-xml</a></p> <h3 id="summary-data-model-changes">Data model changes</h3> <p>Wherever version identifiers are stored, three positions should be allowed.</p> > Related issue: [Issue #2622450](https://www.drupal.org/node/2622450) > Related issue: [Issue #1612910](https://www.drupal.org/node/1612910) > Related issue: [Issue #3009338](https://www.drupal.org/node/3009338) > Related issue: [Issue #3074993](https://www.drupal.org/node/3074993) > Related issue: [Issue #3100115](https://www.drupal.org/node/3100115)