silverstripe-installer/composer.json

{
	"name": "silverstripe/installer",
	"description": "The SilverStripe Framework Installer",
	"require": {
		"php": ">=5.3.3",
		"silverstripe/cms": "self.version",
		"silverstripe/framework": "self.version",
		"silverstripe/reports": "self.version",
		"silverstripe/siteconfig": "self.version",
		"silverstripe-themes/simple": "3.1.*"
	},
	"require-dev": {
		"phpunit/PHPUnit": "~3.7"
	},
	"config": {
		"process-timeout": 600
	},
	"prefer-stable": true,
	"minimum-stability": "dev"
}
Added composer.json Once we've sorted out packagist listing ownership, we should be able to remove the custom repository entries. 2012-11-01 17:26:18 +01:00			`{`
			`"name": "silverstripe/installer",`
			`"description": "The SilverStripe Framework Installer",`
			`"require": {`
Updated minimum php version 2015-06-25 12:42:57 +12:00			`"php": ">=5.3.3",`
FIX: Put self.version in composer dependencies. 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. 2013-05-13 21:07:57 +12:00			`"silverstripe/cms": "self.version",`
			`"silverstripe/framework": "self.version",`
Set reports and siteconfig version dependency 2015-06-18 11:41:59 +12:00			`"silverstripe/reports": "self.version",`
			`"silverstripe/siteconfig": "self.version",`
Prefer stable packages while still allowing dev ones. Fixes #100 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. 2015-07-03 17:34:58 +01:00			`"silverstripe-themes/simple": "3.1.*"`
Added composer.json Once we've sorted out packagist listing ownership, we should be able to remove the custom repository entries. 2012-11-01 17:26:18 +01:00			`},`
Added phpunit to dev dependencies 2015-02-26 14:21:47 +13:00			`"require-dev": {`
Prefer stable packages while still allowing dev ones. Fixes #100 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. 2015-07-03 17:34:58 +01:00			`"phpunit/PHPUnit": "~3.7"`
Added phpunit to dev dependencies 2015-02-26 14:21:47 +13:00			`},`
Include a higher timeout value to avoid timeouts. Checking out framework can often take longer than the default (300 seconds). This gives a 10min limit to creating a new project. 2013-03-06 20:22:48 +13:00			`"config": {`
Added phpunit to dev dependencies 2015-02-26 14:29:38 +13:00			`"process-timeout": 600`
Include a higher timeout value to avoid timeouts. Checking out framework can often take longer than the default (300 seconds). This gives a 10min limit to creating a new project. 2013-03-06 20:22:48 +13:00			`},`
Prefer stable packages while still allowing dev ones. Fixes #100 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. 2015-07-03 17:34:58 +01:00			`"prefer-stable": true,`
Added composer.json Once we've sorted out packagist listing ownership, we should be able to remove the custom repository entries. 2012-11-01 17:26:18 +01:00			`"minimum-stability": "dev"`
NEW: Added dev dependencies to composer. FIX: Don't hardcode framework and cms version in installer. 2012-11-04 21:24:59 +13:00			`}`