Problem/Motivation

At #2991207: Drupal core should inform the user of the security coverage for the site's installed minor version including final 8.x LTS releases, the latest patches are introducing a ProjectSecurityData::getSemanticMinorVersion() method to get the minor version out of a semantic version string. I've flagged this as weird in my reviews over there. We already have a ModuleVersion class for exactly this kind of thing. Let's put the code there, not in the new ProjectSecurityData class.

Proposed resolution

Add ModuleVersion::getMinorVersion() for use by ProjectSecurityData and others.

Remaining tasks

  1. Write code
  2. Update tests
  3. Review
  4. RTBC
  5. Commit

User interface changes

N/A

API changes

Adds a new getMinorVersion() method to the (internal / final) ModuleVersion class.

(Also adds a $minor_version argument to the constructor, but that's already private so it doesn't matter).

Data model changes

N/A

Release notes snippet

N/A

CommentFileSizeAuthor
#2 3110223-2.patch7.86 KBdww

Comments

dww created an issue. See original summary.

dww’s picture

dww
we/he/they
commented
Assigned: dww » Unassigned
Issue summary: View changes
Status: Active » Needs review
StatusFileSize
new 3110223-2.patch7.86 KB

Okay, I guess it's a little more than 5 lines of code and 20 lines of tests. ;) But still, this seems way better than the alternative, and now we've got test coverage, too.

xjm’s picture

xjm
she/her
Primary language English
commented

As @tedbow pointed out, we can't simply call the second number in the version string the minor version, because for pre-semver contrib releases (or pre-D8 core releases), the versions are just major.patch. For that reason, I think this adds complexity/confusion and is wontfix for now.

dww’s picture

dww
we/he/they
commented

@xjm, thanks for the review. Some arguments in support of this patch:

  1. Just because I wrote a handbook page 10+ years ago that said if the version is 8.x-1.2, 2 == "patch level" doesn't make it so. ;)
  2. Ever since the d.o composer shim went live, we've called that 2 the "minor" version, mapping the above into the "1.2.0" release.
  3. Many contrib authors have been treating their two digits as major.minor for semantic purposes, including stuff like 8.x-1.3-rc2 releases to prep for the "official" 8.x-1.3 release.
  4. The internals of Project* now consider the "2" the "minor version".
  5. This code will never run with D7 core, so the fact that D7 releases are non-semver doesn't matter. In fact, it seems like the parent issue is headed towards this code never being called with non-semver contrib releases, either. Even if it is called with BespokeVer contrib, it's no harm in parsing 8.x-1.2 such that we treat the 2 as "minor".
  6. The patch is already smart enough to not blindly take the 2nd digit, but handles both 8.x-1.2 and 8.8.2 properly.
  7. We now have a value object in 8.9.x branch called "ModuleVersion" that only supports "major" and "extra". I think that's some DX-WTF and confusion on its own. This patch moves us closer to a fully-functional value object that could be made a public API some day (it's currently all final and @internal, although I'd like to see that changed).

...

Please don't won't fix. ;)

Thanks,
-Derek

xjm’s picture

xjm
she/her
Primary language English
commented
Status: Needs review » Postponed

Just because I wrote a handbook page 10+ years ago that said if the version is 8.x-1.2, 2 == "patch level" doesn't make it so. ;)

The past 10 years of Drupal development, OTOH, do make it so. Also, the changes we allow in those versions make it so. Drupal 7 had basically no new features introduced after its release because each release (e.g. 7.67) followed semver guidelines for the allowed changes of patch releases. For this reason, any API addition here to consider minor or patch versions should also take this into account. Giving something the name "minor" when people in the community have called it a patch release for a decade is going to lead to confusion.

Therefore, this will need more thought put into any naming or documentation around minors and patches than what's in the patch currently.

We now have a value object in 8.9.x branch called "ModuleVersion" that only supports "major" and "extra".

This object is marked @internal and final with a private constructor. It's not meant for use for anything outside the update system. We can add additional properties to it if we want later, but we shouldn't just add them because we don't want a one-liner somewhere else without a second usecase and especially with the confusion described above.

So, I am postponing this issue for now. We can revisit it if:

  • Further needs for it turn up in the process of the update module improvements we're making.
  • We have a strategy to distinguish with the API between "old patch" version and "new minor.patch versions" in a way that developers will understand by reading the method names.
  • We pass the point where any old-style non-semver releases for any contrib are supported.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.