Problem/Motivation

Took me a while to notice the message on the project page about needing the 2.x version of xls_serialization, you could add declare this dependency in your info file too.

Steps to reproduce

Proposed resolution

Add the version constraint to the info file.

Remaining tasks

User interface changes

API changes

Data model changes

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

steven jones created an issue. See original summary.

mably made their first commit to this issue’s fork.

mably’s picture

Status: Active » Needs review

Thanks for the report — good catch.

Opened MR !1 mirroring the composer.json constraint (^2.1) as (>=2.1) on the xls_serialization entry in views_data_export_excel.info.yml, so the requirement surfaces in Drupal's module install UI and dependency checker, not only via Composer.

steven jones’s picture

Status: Needs review » Reviewed & tested by the community

Nice!

mably’s picture

Thanks for the review, let's merge this!

  • mably committed c5ae05e0 on 1.x
    fix: #3590125 Explicitly declare the dependency on the 2.x branch of...
mably’s picture

Status: Reviewed & tested by the community » Fixed

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

mably’s picture

Fix included in the 1.0.1 release.

mably’s picture

Merging MR !2 (the simple (>=2.1) revert) for now.

The constraint as written breaks update.php for any site running xls_serialization's dev branch. PHP's version_compare treats the x in 2.1.x-dev as a string less than any digit, so 2.1.x-dev compares as less than 2.1 and SystemRequirements rejects the install. We ship dev versions on production instances, so this hit us at the "Verify requirements" step of update.php.

Drupal's Component\Version\Constraint parser also only captures major.minor from a constraint string, so no info.yml expression can both accept 2.1.x-dev and reject 2.0.x — every attempt (>=2.0.999, >=2.0.0-zzz, etc.) collapses to >=2.0 and lets 2.0.x stable through.

The composer.json ^2.1 constraint already enforces the minimum at install time and understands dev versions natively, so dropping the info.yml constraint to a presence check does not lose real enforcement.

An alternative PHP-based enforcement (visible in Drupal's module install UI, dev-version aware) is in MR !3 — InstallRequirementsInterface + #[Hook('runtime_requirements')] using Composer's own Semver. Kept open as a follow-up.

  • mably committed 274489e6 on 1.x
    Issue #3590125: Revert the (>=2.1) info.yml dep constraint — breaks dev-...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.