This is required here in order for the "cow" release tool
to include the module in tagging releases.
At the moment, it's only an indirect asset-admin dependency,
but will become a framework dependency once we switch
CampaignAdmin to use GraphQL as well.
Although the original ticket recommended increasing our
minimum-stability, this change gives us the best of both worlds.
- Where stable packages are available and meet the requirements, they
will be used.
- Where stable packages aren’t available or they don’t meet the
dependency requirements, non-stable packages are still allowed.
As part of this I have also tightened up the silverstripe-themes req
version, as “*” is an anti-pattern. The versioning of the theme has
rightly split off from the versioning of the framework; it looks like
3.1.* is what we should expect.
Arguably, we could set the dependency to ~3.1, but in this case I think
it’s fine to be conservative.
With this change, composer will automatically call dev/build after an update or install
command. The main reason that this is 3.1-only is that previous releases would have
necessitated the use of 'sudo -u www-data', which is too environment-specific.
One thing that this may cause problems with is 'composer create-project' in an environment
without a _ss_environment file. It will call dev/build, and dev/build will throw an
error. That should be fixed in a subsequent commit.
Now that https://github.com/composer/composer/pull/1883 is in Composer, self.version
will work as a requirement for framework & cms. This will simplify the release
process a great deal.
Ultimately, the release of rc1 will be the place to test that, but it seems appropriate
to get this in there for that.
If it succeeds with 3.1-rc1, I'd suggest we backport to 3.0 and 2.4.
Any "composer require <module>" call will first call
a "composer update". This *automatically* includes dev requirements,
without providing a way to turn off this behaviour.
A workaround would be "composer require --no-update <module> && composer update --no-dev <module>",
but that drastically reduces the usefulness of the command
for our target audience (moderately technical devs).
In the end, the small faction of devs needing the dev dependencies
also know how to install them on their own. And having a local phpunit
build actually gets in the way more than it helps in case you have
it installed through PEAR already (can get really weird when using the
PEAR provided "phpunit" binary, but the autoloader finds the composer managed classes).
They used to require manual editing of the composer.json
file in order to do a proper dev checkout. In the end,
the choice between release tag and dev branch should
be handled by composer already via the --stability flag.
