- Separate Travis branch deployment and release deployment stages (also makes `deploy.sh` obsolete)
- Add `clean.sh` and `release.sh` scripts to allow users to create "release" packages locally
- Use `setup/*.sh` scripts to check and install build dependencies (like PHP_CodeSniffer, phpDocumentor and cloc)
- Use `create-release.sh` of `picocms/ci-tools` to create release archives
- Streamline script usage
Use the following to test Pico and to create a "release" package locally:
```sh
cd ~/My-Pico-Workspace/Components/pico
ln -rs ../ci-tools .build/ci-tools
. ./.build/ci-tools/init/local.sh.inc
. ./.build/init.sh.inc
phpcs --standard=.phpcs.xml "$PICO_PROJECT_DIR"
clean.sh
release.sh
```
Otherwise Composer downloads a newer version of Twig which isn't compatible with PHP 5.3. Since we don't pin down specific versions of our dependencies, Composer-based installations might use newer versions of Twig which aren't compatible with PHP 5.3. Raising the PHP requirements requires a new major version, something that will definitly happen with Pico 3.0.
HHVM 4 no longer supports execution of PHP code. HHVM 3.30 and 3.27 are the only remaining still supported HHVM versions with PHP support. They will reach end-of-life in the course of 2019.
Due to the fact that Travis uses a shallow clone of Pico's Git repo, composer has no chance to detect on which branch it currently is. This was no big deal with Pico 1.0, however, Pico 2.0 depends on picocms/pico-deprecated and picocms/pico-theme. We use composer's `self.version` version constraint to sync the version numbers of these separate Git repos. Thus composer must know Pico's current version to resolve these dependencies. We try to guess the current version either using known branch aliases in Pico's `composer.json`, or using the `Pico::VERSION` constant (see `_build/install.sh`).
Daniel Rudolf
theshka