See https://github.com/chillu/silverstripe-buildtools. Will migrate to https://github.com/silverstripe/silverstripe-buildtools once approved.
Two reasons: There's a lot of cruft in the default checkout which is only really required for a handful of developers, for example the getlocalization sync targets. But more importantly because versioning becomes a hassle: The build tools are 95% the same between releases. For 2.4 we don't have any build tools set up, which complicates releases. I've added support light logic branching and a simple version_compare() statement.
One example is missing the replacements in the silverstripe_version files in the last couple of 2.4.x releases (basically all of them since we switched from SVN). Stuff like that is automated in 3.x, and it should be in 2.x as well.
I've left the 'phing phpunit' and 'phing behat' tasks in their original place, since they're useful for any community dev.
The whole 'dependent-modules' and 'new-project' logic has been removed from the new module, in favour of composer. The build system could take more advantage of composer metadata, but its a start.
Also submitted a pull request to fix the docs: silverstripe/silverstripe-framework#962
Once this is merged, I'll check the release docs on the bert wiki, TeamCity builds, create a silverstripe/silverstripe-buildtools repo and according packagist package.
API Moved build tools to new silverstripe-buildtools module
API Removed 'new-project' command
Use 'compass create-project silverstripe-installer' instead
This seems fine to me; if @hafriedlander doesn't have any objection I say we merge it.
Ingo, are you aware that https://github.com/silverstripe/silverstripe-buildtools is an existing repository? Most of the content of that repo is rendered obsolete by Composer but it does raise the point that buildtools would be usefully designed such that it was a collection of tools that could be used for other projects. For example:
I'd be more comfortable with the split out if we were seeing this as a decoupling of the buildtools, rather than merely sharding a tightly coupled build.xml file into a separate repo.
It doesn't need to be done before the split; those could be issues created on the new repo; but it's good to set a clear picture of where the repo is heading.
Yeah, seems fine to me too. Should we make the buildtools module a "requirements-dev" requirement? Also, I think we can trash new-project completely now - was just a hacked up tool until composer worked.
From what I can tell, we can completely replace that other repo, maybe add back some help text from silverstripe-archive/silverstripe-buildtools@4fdac3a.
Do you see any value in keeping the bootstrap(3).php stuff around in there - is it used in internal builds?
We have those files in the core branches, and have been happily running phpunit projects off those for a while.