Composer version constraints on your modules

[Ingo Schommer]

Hello!

tldr; Module authors will need to update their composer.json, otherwise users of the module on beta/rc releases will see errors.

We've been advocating the usage of composer to install modules for a while now (install instructions, module instructions).

This requires module authors to include a composer.json in their codebase, and declare

dependencies and compatible SilverStripe versions.

Given the deeper changes in 3.1 (such as marking statics as private), a lot of modules will

need a separate release branch for 3.0 compatibility, while keeping master (or another release branch) compatible with 3.1.

We used to declare this as follows in composer.json

{

  "require": {"silverstripe/framework": "~3.1"},

  ...

}

The constraints basically means "any version greater than 3.1, up until the next significant release, so 4.0".

It ensures you can use your module with later releases and master versions of the framework.

But this caused issues with failed dependencies when using a pre-release such as 3.1.0-beta3,

since "greater than 3.1" doesn't include "3.1.0-beta3".

So the updated way to write this constraint is as follows:

{

  "require": {"silverstripe/framework": ">=3.1.x-dev,<4.0"},

  ...

}

This is more or less a temporary measure, since ~.3.1 will work once we release 3.1.0.

But you'll have the same trouble in the future for having a minimum dependency on a 3.2 pre-release,

so its worth documenting. This blog post will give you a bit of background on semantic versioning and composer.

I've updated most modules in the "silverstripe" vendor namespace, let me know if I've missed any.

BTW, if you've seen a lot of symfony and phpunit dependencies coming down when using "composer require",

we consider this a bug in composer (shouldn't install dev requirements in this case): https://github.com/composer/composer/issues/1874

Ingo

---

Ingo Schommer | Senior Developer
SilverStripe (http://silverstripe.com)
Skype: chillu23