We need to think about the intended use for each of the projects where we use Phing and group them according to similarities in the steps necessary to produce a public release. Then we need to design our build targets to apply to those types of projects. Here's a grouping that comes to mind:
WordPress plugins/themes
WebSharks libraries
With that in mind, we could have build targets with names like -build-wp, -build-all-wp, -build-lib, -build-all-lib, etc.
We've come a long way with our Phing build system without hitting a divergence point (which came up in https://github.com/websharks/phings/issues/76, but was later resolved by a change in the Comet Cache project).
The "Cleanups" classification @jaswsinc mentioned, referring to the new -js-css target, makes it clear that some projects will need to generate a .~build/ directory, make some changes to its content, and then package that directory for distribution. (Currently packaging happens before .~build/ is populated and the packages are sourced from the repo directory, not the .~build/ directory.)
So we should create -build-wp and -build-lib targets, and let those contain collections of other targets that apply to the appropriate project type.
Forking from discussion in https://github.com/websharks/phings/issues/76#issuecomment-208292062.
We need to think about the intended use for each of the projects where we use Phing and group them according to similarities in the steps necessary to produce a public release. Then we need to design our build targets to apply to those types of projects. Here's a grouping that comes to mind:
With that in mind, we could have build targets with names like
-build-wp
,-build-all-wp
,-build-lib
,-build-all-lib
, etc.We've come a long way with our Phing build system without hitting a divergence point (which came up in https://github.com/websharks/phings/issues/76, but was later resolved by a change in the Comet Cache project).
The "Cleanups" classification @jaswsinc mentioned, referring to the new
-js-css
target, makes it clear that some projects will need to generate a.~build/
directory, make some changes to its content, and then package that directory for distribution. (Currently packaging happens before.~build/
is populated and the packages are sourced from the repo directory, not the.~build/
directory.)So we should create
-build-wp
and-build-lib
targets, and let those contain collections of other targets that apply to the appropriate project type.