1. Source Control of Composer project
I normally ignore the vendor directory using .gitignore. Indeed, this is so common that .gitignore file comes with most PHP framework would have already included the vendor directory.
Upon release, some of the steps will be:
- checkout or clone from release branch/tag,
- update composer ( self update )
- composer install ( install all dependencies into the vendor directory )
2. Composer versoining/stability/alias confusion
Yes this is confusing, I think the most confusing part is where versions come from, and it is not easy found in the online docs. Versions come from source control's branches and tags
- a Tag name is the exact version name. if you have a tag called 'xx', you can reference it in the package.json file as 'xx'. if your tag follows the semantic naming convention (e.g. 1.0.1 or v1.0.1), you can refer to it using semantic syntax like ~1.0.*.
- tags are 'stable' UNLESS their semantic names contains somethings like 'RC1', 'RC2', 'alpha' etc. (e.g. 1.0.1-rc1, 1.0.1-alpha) In those cases they can be referenced by 1.0.1@RC or 1.0.1@alpha.
- branches are not 'stable' by default, numbered branch will be treated as development version. e.g. branch 2.0 will be referenced as 2.0.x-dev (note the extra .x ); Non-numbered branch name will be referenced with be prefixed with 'dev-'. i.e. 'master' branch becomes dev-master and 'testing' branch becomes dev-testing.
- Branch alias is used, for example, when you want to treat the master branch as 2.0.x@dev. You might want to use the dev-master branch of package ABC but it happens that one of the packages you used in your project depends on the 2.0 branch of package ABC. As you can only use one version of package ABC in your project, you basically ask all other packages to use the dev-master when they want to use the 2.0.x@dev branch
Other issues like minimum-stability and nested dependencies are clear in the online docs and I am not repeating them here.
