Composer version constraints: to fix or not to fix ?

[jrfnl]

In PR #81, I updated the WPCS dependency to ^1.0.0:

yoastcs/composer.json

Line 25 in f80e431

"wp-coding-standards/wpcs": "^1.0.0",

WPCS will be using semantic versioning. In practice, this means that:

• Patch versions will only contain bug fixes and changes which do not impact sniffing (readme updates and such).
• Minor version can contain new features, such as new sniffs, either WPCS native ones or adding upstream ones via the ruleset.
• Major versions can contain BC-breaks, i.e. removed support for previously deprecated behaviour and such.

Most of the repos which use YoastCS have a compose.lock file committed in the repo. For those the above is fine, as updates to the composer.lock will be managed.

A few repos - IIRC i18-module and WHIP, though possibly one or two more - don't have a committed composer.lock file. For those repos, the above version setting could cause unexpected build breaking when a new (minor) version of WPCS has been released and Travis would use the latest version when doing a composer install and the subsequent phpcs run.

So my question is:
👉 Should the WPCS dependency in YoastCS be limited to patch versions ? i.e. use ~1.0.0 instead.

The same could, of course, be said about the PHP_CodeSniffer and PHPCompatibilityWP dependencies.
For those, I strongly suggest leaving the dependency setting as is, i.e. ^#.#.

• For PHP_CodeSniffer: while higher versions of PHPCS may include new sniffs, those sniffs will not automatically be included as that is managed by WPCS. So allowing higher versions should be fine as these will contain bug fixes which the projects benefit from.
• For PHPCompatibilityWP: while higher minors will contain new sniffs, if this leads to breaking builds, that's a good thing as it generally means that a cross-version compatibility bug in the code has been discovered which should be fixed with high priority anyway.

[atimmer]

I would say go for ^1.0.0.

[jrfnl]

@atimmer Thanks for your response. In that case, I'll close this issue, but at least the reasoning and the decision has now been documented.