Since it excludes behat.yml and phpunit.xml.dist,
and "composer install" uses github archives for stable versions,
you can't use projects installed this way for testing any more.
To make matters worse, the error you get on a "phpunit" run
is very confusing ('class SapphireTest not found').
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.
Partially reverts e9f13512dc
This caused two issues in Travis builds:
* CMS builds were using
outdated framework dependencies. Example: https://travis-ci.org/silverstripe/silverstripe-cms/jobs/7718686
* Modules weren't building
at all because the info in the lock file overwrote the custom
composer.json. Example: https://travis-ci.org/silverstripe/silverstripe-translatable/jobs/7726954
In addition, I don't agree with having lock files on release branches
(as opposed to tags), since it forces us to permantently update lock
files or work with stale dependencies even when on branches
(most likely not the developers intention).
Now that Composer has been fixed, self.version can be used as a dependency for framework
and cms in installer. This simplifies our composer.json, and meanst that we can commit
composer.lock into the repo, as required. An annoying piece of our release process has
been solved!
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 can expose version information, so shouldn't be accessible
through the web. The better solution of course is to move
to a public/ subfolder application structure.
This is useful for keeping standard "composer create-project"
checkouts clean. Unless they use "--keep-vcs", in which case
.gitattributes is (correctly) ignored.
This has the side effect that archive-checkouts can't
run phing or phpunit scripts, but I think that's
acceptable.
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.
Due to git limitations, we can't check out the blackcandy
"parent" theme into themes/blackcandy/ directly, since that
would require sharing paths with git repositories of other themes.
Damian Mooyman
Christopher Pitt
Sean Harvey
Ingo Schommer
Ingo Schommer
Sam Minnee
Hamish Friedlander
Simon Welsh
colymba
Nicolaas
Will Rossiter
Sean Harvey